On 08/25/2009 08:38 PM, Pavel Machek wrote:
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.
You are deliberately causing a double failure - pressing the power button
after pulling a drive is exactly that scenario.
Exactly. And now I'm trying to get that documented, so that people
don't do it and still expect their fs to be consistent.
The problem I have is that the way you word it steers people away from RAID5 and
better data integrity. Your intentions are good, but your text is going to do
considerable harm.
Most people don't intentionally drop power (or have a power failure) during RAID
rebuilds....
Pull your single (non-MD5) disk out while writing (hot unplug from the
S-ATA side, leaving power on) and run some tests to verify your
assertions...
I actually did that some time ago with pulling SATA disk (I actually
pulled both SATA *and* power -- that was the way hotplug envelope
worked; that's more harsh test than what you suggest, so that should
be ok). Write test was fsync heavy, with logging to separate drive,
checking that all the data where fsync succeeded are indeed
accessible. I uncovered few bugs in ext* that jack fixed, I uncovered
some libata weirdness that is not yet fixed AFAIK, but with all the
patches applied I could not break that single SATA disk.
Pavel
Fsync heavy workloads with working barriers will tend to keep the write cache
pretty empty (two barrier flushes per fsync) so this is not too surprising.
Drive behaviour depends on a lot of things though - how the firmware prioritizes
writes over reads, etc.
ric
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
