Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
partially degraded raid 6 _IS_ vunerable to partial writes on power failure
Posted Sep 1, 2009 17:33 UTC (Tue) by dlang (✭ supporter ✭, #313)
Date: Wed, 26 Aug 2009 09:28:50 +1000
From: Neil Brown <email@example.com>
Subject: Re: [patch] ext2/3: document conditions when reliable operation is possible
On Monday August 24, firstname.lastname@example.org wrote:
> > +Don't damage the old data on a failed write (ATOMIC-WRITES)
> > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > +
> > +Either whole sector is correctly written or nothing is written during
> > +powerfail.
> > +
> > + Because RAM tends to fail faster than rest of system during
> > + powerfail, special hw killing DMA transfers may be necessary;
> > + otherwise, disks may write garbage during powerfail.
> > + This may be quite common on generic PC machines.
> > +
> > + Note that atomic write is very hard to guarantee for RAID-4/5/6,
> > + because it needs to write both changed data, and parity, to
> > + different disks. (But it will only really show up in degraded mode).
> > + UPS for RAID array should help.
> Can someone clarify if this is true in raid-6 with just a single disk
> failure? I don't see why it would be.
It does affect raid6 with a single drive missing.
After an unclean shutdown you cannot trust any Parity block as it
is possible that some of the blocks in the stripe have been updated,
but others have not. So you must assume that all parity blocks are
wrong and update them. If you have a missing disk you cannot do that.
To take a more concrete example, imagine a 5 device RAID6 with
3 data blocks D0 D1 D2 as well a P and Q on some stripe.
Suppose that we crashed while updating D0, which would have involved
writing out D0, P and Q.
On restart, suppose D2 is missing. It is possible that 0, 1, 2, or 3
of D0, P and Q have been updated and the others not.
We can try to recompute D2 from D0 D1 and P, from
D0 P and Q or from D1, P and Q.
We could conceivably try each of those and if they all produce the
same result we might be confident of it.
If two produced the same result and the other was different we could
use a voting process to choose the 'best'. And in this particular
case I think that would work. If 0 or 3 had been updates, all would
be the same. If only 1 was updated, then the combinations that
exclude it will match. If 2 were updated, then the combinations that
exclude the non-updated block will match.
But if both D0 and D1 were being updated I think there would be too
many combinations and it would be very possibly that all three
computed values for D2 would be different.
So yes: a singly degraded RAID6 cannot promise no data corruption
after an unclean shutdown. That is why "mdadm" will not assemble such
an array unless you use "--force" to acknowledge that there has been a
Posted Sep 4, 2009 23:32 UTC (Fri) by giraffedata (subscriber, #1954)
But you don't have to build a RAID6 array that way. Ones I've looked at use a journaling scheme to provide atomic parity update. No matter where you get interrupted in the middle of updating a stripe, you can always get back the pre-update parity-consistent stripe (minus whatever 1 or 2 components that might have died at the same time).
I suspect Linux 'md' doesn't have the resources to do this feasibly, but a SCSI RAID6 unit probably would. I don't expect there's much market for the additional component loss protection of RAID6 without getting the interrupted write protection too.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds