| |||||||||||||
ext4 and data lossext4 and data lossPosted Mar 13, 2009 13:26 UTC (Fri) by man_ls (subscriber, #15091)In reply to: ext4 and data loss by rahulsundaram Parent article: ext4 and data loss That sounds like a circular argument: distros don't have XFS or JFS experts because nobody cares about them anymore, and nobody cares about them because distros don't have experts. But the code to all these filesystems is open and has been there for a long while; why do distros have ext3 experts to begin with? The real reason ext3 is popular is (or so I contend) that it is stable and crash-resistant by default. Crash resistance may have been an design accident in the beginning, but it is what got it to be the most popular filesystem for Linux. It would seem that people are not so willing to trade robustness for speed. After all the mission of a filesystem is to keep your data until you ask for it; is it any wonder that people like it when it does just that, no matter what?
(Log in to post comments)
ext4 and data loss Posted Mar 15, 2009 19:32 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]
It isn't a circular argument. Ext2 already existed before these other filesystems and Ext3 being the only filesystem backward compatible with it and using a very similar codebase meant that it had a leg up with distributions and users trusting it more and adopting it far more quickly. Also while Ext* has been a cross vendor effort, other filesytems like JFS and XFS were developed by a single company like SGI or IBM and never grew out of it. Btrfs made a deliberate effort to avoid this problem and has succeeded in doing so.
ext4 and data loss Posted Mar 17, 2009 22:01 UTC (Tue) by pphaneuf (guest, #23480) [Link] My favourite characteristic of the extX family of filesystem is the ability to fsck while it being mounted. Often overlooked, but wow, do you ever miss that when you have to work with another filesystem for a period of time...
ext4 and data loss Posted Mar 17, 2009 22:37 UTC (Tue) by nix (subscriber, #2304) [Link]
*Why* do you miss the bizarre and dangerous ability to fsck a mounted
filesystem, often with umount-or-reboot-pleeze following it? Because your early userspace is too deficient to fsck / before mounting it?
ext4 and data loss Posted Mar 17, 2009 22:59 UTC (Tue) by quotemstr (subscriber, #45331) [Link]
I assume he's talking about a read-only fsck. Any decent fsck should refuse to modify a mounted filesystem.
I agree, though, that even a read-only fsck of a filesystem mounted read-write doesn't seem that useful --- the on-disk state of a mounted filesystem is going to be slightly inconsistent anyway: it's likely that not everything has been flushed to disk yet.
Now a full (read and fix) fsck of a filesystem mounted read-only may be useful, and tolerably dangerous if followed immediately by a reboot.
ext4 and data loss Posted Mar 17, 2009 23:45 UTC (Tue) by nix (subscriber, #2304) [Link]
Indeed fsck.ext[234] is perfectly happy to modify a read-only-mounted /.
It even has special behaviour (messages and exit codes) to tell you when you have to reboot because it just modified a mounted filesystem.
I still think it's a disgusting cheap hack sanctified only because that's
|
|||||||||||||