"David Wilk" writes: > this was exactly my thought. I was hoping someone would have some > 'official' knowledge, or opinion. I still can't get over having to > wait several hours for my root partition to become available after an > improper shutdown. > > On 3/18/06, Joachim Schipper <[EMAIL PROTECTED]> wrote: > > On Sat, Mar 18, 2006 at 12:59:30PM +0200, Antonios Anastasiadis wrote: > > > I had the same question, and just changed the relevant line in /etc/rc > > > adding '&' in the end: > > > > > > raidctl -P all & > > > > Then again, why is this not the default? Are you certain this actually > > works? > > > > Joachim
If you want to be 100% paranoid, then you want to wait for the 'raidctl -P all' to update all parity before starting even fsck's. There *is* a non-zero chance that the parity might be out-of-sync with the data, and should a component die before that parity has been updated, then you could end up reading bad data. This can happen even if the filesystem has been checked. What are the odds of this happening? Pretty small. If 'raidctl -P all &' is run, then the larger problem is both fsck and raidctl will be fighting for disk cycles -- i.e. the fsck will take longer to complete. On more "critical" systems, this is how I typically have things setup (I'm willing to risk it that I'm not going to have a disk die during the minutes that it takes to do the fsck). On less critical boxes, I've got a "sleep 3600" before the 'raidctl -P', so that the parity check doesn't get in the way of the fsck or the system coming up... about an hour after it comes up, the disks are then checked... It's one of those "what are the odds" games... allowing the raidctl to run in the background seems to have the right mix of paranoia and practicality... Later... Greg Oster
