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]

Reply via email to