On Tue 2009-08-25 19:48:09, Ric Wheeler 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. > 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). >> Otherwise, file systems placed on these devices can suffer silent data >> and file system corruption. An forced use of fsck may detect metadata >> corruption resulting in file system corruption, but will not suffice >> to detect data corruption. >> > > This is very misleading. All storage "can" have silent data loss, you are > making a statement without specifics about frequency. substitute with "can (by design)"? Now, if you can suggest useful version of that document meeting your criteria? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
