On Wed, 26 Aug 2009, Pavel Machek wrote:
---
There are storage devices that high highly undesirable properties
when they are disconnected or suffer power failures while writes are
in progress; such devices include flash devices and MD RAID 4/5/6
arrays. These devices have the property of potentially
corrupting blocks being written at the time of the power failure, and
worse yet, amplifying the region where blocks are corrupted such that
additional sectors are also damaged during the power failure.
I would strike the entire mention of MD devices since it is your
assertion, not a proven fact. You will cause more data loss from common
That actually is a fact. That's how MD RAID 5 is designed. And btw
those are originaly Ted's words.
Ted did not design MD RAID5.
So what? He clearly knows how it works.
Instead of arguing he's wrong, will you simply label everything as
unproven?
events (single sector errors, complete drive failure) by steering people
away from more reliable storage configurations because of a really rare
edge case (power failure during split write to two raid members while
doing a RAID rebuild).
I'm not sure what's rare about power failures. Unlike single sector
errors, my machine actually has a button that produces exactly that
event. Running degraded raid5 arrays for extended periods may be
slightly unusual configuration, but I suspect people should just do
that for testing. (And from the discussion, people seem to think that
degraded raid5 is equivalent to raid0).
Power failures after a full drive failure with a split write during a rebuild?
Look, I don't need full drive failure for this to happen. I can just
remove one disk from array. I don't need power failure, I can just
press the power button. I don't even need to rebuild anything, I can
just write to degraded array.
Given that all events are under my control, statistics make little
sense here.
if you are intentionally causing several low-probability things to happen
at once you increase the risk of corruption
note that you also need a write to take place, and be interrupted in just
the right way.
David Lang
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html