| |||||||||||||
|
| |||||||||||||
Journal-guided RAID resyncJournal-guided RAID resyncPosted Nov 26, 2009 21:34 UTC (Thu) by nix (subscriber, #2304)In reply to: Journal-guided RAID resync by neilbrown Parent article: Journal-guided RAID resync
My worry is that between the time when the new data is written, and the
time when the parity block is updated (or vice versa if the parity write gets to the disk surface first), if you have a crash, bingo, you have instant corruption of that stripe. There isn't any way to make those two writes happen in sync, after all.
(I *know* you know this, so am quite mystified that you're apparently
(Log in to post comments)
Journal-guided RAID resync Posted Nov 27, 2009 1:14 UTC (Fri) by neilbrown (subscriber, #359) [Link]
You only have "instant corruption" if the array becomes degraded before the parity gets corrected. For this reason mdadm will not assemble an array which is both dirty and degraded. I thought I had mentioned this in my original comment, but apparently not. Maybe this is the case implied in the original article, though I don't think the text really matches reality: Either there is a correct fix that is trivial, or no fix is possible.
(The only two ways to avoid corruption when a crash happens on a degraded array are 1/ to journal updates at the raid level, or 2/ use a copy-on-write filesystem that knows about the stripe size and only ever writes into a stripe that does not contain any important information.).
Journal-guided RAID resync Posted Nov 27, 2009 6:56 UTC (Fri) by nix (subscriber, #2304) [Link]
Aaah, I see (actually whenever you mention this I get it for a few minutes
and then it blurs out of memory again). Yes, that makes sense: if you don't lose a disk, you have two intact stripes and one stripe containing not-yet-written garbage: whether that's the parity stripe or not is immaterial.
So the thing to be worried about here is that RAID-5 only really protects
And I suspect this is the case the article was discussing.
|
|
||||||||||||