>>> I have to admit that I have not paid enough attention to this >>> specifics of your ext3 + flash card issue - is it the ftl stuff >>> doing out of order IO's? >> >> The problem is that flash cards destroy whole erase block on unplug, >> and ext3 can't cope with that. > > Even if you unmount the file system? Why isn't this an issue with > ext2? No, I'm talking hot unplug here. It is the issue with ext2, but ext2 will run fsck on next mount, making it less severe. >>> Pull them even after an unmount, or pull them hot? >>> >> >> Pull them hot. >> >> [Some people try -osync to avoid data loss on flash cards... that will >> not do the trick. Flashcard will still kill the eraseblock.] > > Pulling hot any device will cause data loss for recent data loss, even > with ext2 you will have data in the page cache, right? Right. But in ext3 case you basically loose whole filesystem, because fs is inconsistent and you did not run fsck. >>> Again, you say RAID5 without enough specifics. Are you pointing just >>> at MD RAID5 on S-ATA? Hardware RAID cards? A specific commercial >>> RAID5 vendor? >>> >> >> Degraded MD RAID5 on anything, including SATA, and including >> hypothetical "perfect disk". > > Degraded is one faulted drive while MD is doing a rebuild? And then you > hot unplug it or power cycle? I think that would certainly cause failure > for ext2 as well (again, you would lose any data in the page cache). Losing data in page cache is expected. Losing fs consistency is not. >> Degraded MD RAID5 does not work by design; whole stripe will be >> damaged on powerfail or reset or kernel bug, and ext3 can not cope >> with that kind of damage. [I don't see why statistics should be >> neccessary for that; the same way we don't need statistics to see that >> ext2 needs fsck after powerfail.] > What you are describing is a double failure and RAID5 is not double > failure tolerant regardless of the file system type.... You get single disk failure then powerfail (or reset or kernel panic). I would not call that double failure. I agree that it will mean problems for most filesystems. Anyway, even if that can be called a double failure, this limitation should be clearly documented somewhere. ...and that's exactly what I'm trying to fix. 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-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html