configuration choices with Dell CERC (adaptec 2610SA)

Kenneth D. Merry ken at kdm.org
Sun Nov 27 03:20:33 GMT 2005


On Sat, Nov 26, 2005 at 16:44:01 -0700, Scott Long wrote:
> Kenneth D. Merry wrote:
> 
> >On Sat, Nov 26, 2005 at 16:59:56 -0500, user wrote:
> >
> >>First off, thank you very much for your help.
> >>
> >>On Sat, 26 Nov 2005, Scott Long wrote:
> >>
> >>
> >>>The problem is not with filesystem corruption, it's with parity 
> >>>corruption.  It's possible to get a situation where a stripe is
> >>>partially written out and then interrupted by a power failure, leaving
> >>>the parity inconsistent with the stripe.  You won't notice this until
> >>>it's time to rebuild a failed drive from the parity, and then you'll
> >>>get corruption.
> >>
> >>
> >>I will only be creating mirrors.  Is a mirror impervious to this, or are
> >>the potential problems even worse ?  (my guess is impervious .. ?)
> >
> >
> >Mirrors are not impervious to the problem.  You still have the same issue;
> >you don't know whether any outstanding data got written to all drives, some
> >drives or no drives.  If you resync the mirror, you're basically choosing
> >one drive as "good" and the other as "suspect", regardless of what the
> >actual situation is.
> >
> 
> Well, it depends on how the controller recovers from improper shutdown.
> If it forces a full resync, you'll wind up with two drives that are
> consistent with each other.  Whether the data on the drives represents
> everything that the OS thought that it wrote before the crash is a
> different matter, but that is no different than an unclean shutdown with
> only a single disk.  However, if the controller doesn't do a full
> resync, you'll wind up with inconsistencies in the array.  Take disk A1
> and A2 of array A.  You issue writes to sectors 1, 2, and 3 of the
> array.  The controller caches those writes and issues them out to disks
> A1 and A2.  Then catastrophy strikes, and only some of the sectors get
> written.  Disk A1 has sectors 1 and 2 written, and disk A2 has sectors 2
> and 3 written.  The sectors that didn't get written contain old data.
> So now neither disk has data that is of the same age, and if a resync
> isn't done you'll get inconsistent read results from sectors 1 and 3.
> 
> All filesystems have to deal with the fact that not all data will get to
> disk before a crash.  Loosing cached sectors during a RAID-5 write is
> bad because a resync won't restore consistency.  Resyncing a RAID-1 will
> restore consistency, even if it means that new sectors on the resync
> slave get overwritten by older sectors from the resync master.  Having a
> battery for RAID-1 is definitely nice to have, but I don't view it as
> essential since the potential for silent data corruption isn't there.

Resyncing a RAID-5 should restore the consistency of the parity with data.
It's just that you won't know whether or not your data is all good.

You can still have the same sort of problem with a RAID-1.  If one disk was
in the middle of a write when the power failed, you can wind up with a
half-updated chunk of data.  If that disk is picked as the master for the
resync, you'll wind up with a region on the array that is part old and part
new.

In either case, doing a verify will tell you that you have an
inconsistency, but it won't tell you what the data should be.

Ken
-- 
Kenneth Merry
ken at kdm.org


More information about the freebsd-scsi mailing list