----- David Wilk ([EMAIL PROTECTED]) wrote: ----- > Howdy all, > > I've been testing a 3.8 system with RAIDframe and root on raid in a > RAID1 configuration. Performance and stability are quite good, but > there's one thing that's a bit irksome and I wonder if I might not be > doing something right. > > I've had a couple crashes (potentially hardware related) and every > time the RAID requires a parity rebuild. That seems fine, but it > refuses to bring the array on line during this time. It takes several > hours to rebuild a 232GB RAID1 array!
Is the raidframe driver causing the panic? Pedro sent out an email on 2/26 about testing a patch that's being included in 3.9 -STABLE (Subject: Re: raid(4) users, please test this). I had a problem with my 3.2 raidframe mirrors causing the system to panic because a call wasn't being made to VOP_UNLOCK() when VOP_ISLOCKED() was true. I put the disks in my unpatched 3.8 box and I got an immediate panic. Applied the patch and they were fine. > Is this normal? this seems like quite a bit of time to be down with > every improper shutdown of the system. I've used OpenVMS volume shadowing, Solaris Disk Suite (circus Solaris 2.8), software raid for Mac OS system 8, raidframe, etc all for software RAID 1 and all of them took a long time to check after a crash. Essentially when the system hard crashes, it needs to compare the parity information between both disks sector by sector to ensure that the mirrors are in sync. From where I sit, the kernalized raidframe driver stops the system from moving on to multiuser mode until it has verified the disks are both in sync (the safest route to take). Parity for my 100GB volume would take about 90 minutes to check after a crash. Where I've seen it take less time on other implementations is when it pushes the system straight to multiuser mode and checks in the background, which raidframe will do if you hit CTRL-C on the console when it starts checking. You can't pass by the fsck but you can stop the interactive parity check and it will run in the background. > thanks for your thoughts. > > Dave -- John W. Eisenschmidt ([EMAIL PROTECTED]) website: http://www.eisenschmidt.org/jweisen/ my blog: http://thealphajohn.blogspot.com/ house blog: http://4104-chestnut-street.blogspot.com/ Law of False Alerts: As the rate of erroneous alerts increases, operator reliance, or belief, in subsequent warnings decreases. [demime 1.01d removed an attachment of type application/pgp-signature]
