On Thu, Apr 28, 2005 at 10:15:07AM -0500, [EMAIL PROTECTED] said: [ 2+ month TTL due in part to combing through the archives for reports of umass problems with recent snapshots brought this to mind, and I realized I didn't reply back then. Please forgive the severe latency. :)]
> On a related subject, it's painful waiting 20 minutes for the RAID 1 array 20 minutes? Is that all? :) Waiting for parity to rebuild the last time my RAID5 array (4x160GB IDE 5400RPM disks on a PCI IDE controller; very ghetto) took ~14 hours. *sigh* > to rebuild parity after a crash - I vaguely recall it being mentioned last > year, but I can't find it in the archives or any mention in the man pages - > is there a sane way to postpone the parity check? This is what I did - as memory serves, it works, but I haven't tested it on my live system. Not sure how sane this is (I wanted parity to rebuild, in background, on a filesystem that's _not_ automounted, while the rest of the boot process continues and the system comes up): --- /etc/rc Wed May 18 16:54:07 2005 +++ /etc/rc.raidfix Tue Jul 5 23:13:08 2005 @@ -77,8 +77,10 @@ fi done -# Check parity on raid devices. -raidctl -P all +# Check parity on raid devices (but do it in background, so if it needs to +# rebuild, it can do so while the rest of the system comes up. Our RAID fs is +# not automounted at boot, so this should not present a problem). +raidctl -P all & swapctl -A -t blk If this is a Really Bad Idea, I'd appreciate a heads-up to that effect. re-lurking, -- Scott Francis | darkuncle(at)darkuncle(dot)net | 0x5537F527 Less and less is done until non-action is achieved when nothing is done, nothing is left undone. -- the Tao of Sysadmin [demime 1.01d removed an attachment of type application/pgp-signature]