I've become disdained with Linux's pet filesystems as of late. This is for a few very simple reasons:
- ext4 is attempting to be XFS - btrfs is trying to be ZFS Let's shoot down btrfs first, because it'll be easier. btrfs is an enterprise-scale management system similar to LLVM + $FILESYSTEM, more tightly integrated. It does a lot of ridiculous stuff trying to be a VFS layer as well as a filesystem, but that integration can be useful in specialized situations. First argument: Home desktop users don't need all that fancy stuff. This also argues that we don't need LLVM or ZFS on a home end user desktop. Servers, sure. Second argument: btrfs is immature. We know this already of course. It has a fsck that can't fix filesystem errors; it has a version that can, marked "DO NOT USE WILL DESTROY YOUR DATA!!!" Obviously, not production ready. To its merit, btrfs is also trying to be a decent stand-alone filesystem, and offers features like built-in compression etc etc. When it's mature (i.e. has non-broken fsck), it'll probably hold together better on technical merit than old-generation file systems. ext4 is a little harder to shoot down because the technical arguments mainly don't apply. I refer you to 2009: http://lwn.net/Articles/322973/ "ext4 is the new XFS" ext4 has always been about catching up to XFS. XFS is older, has had data loss problems due to exactly how it's proceeded to commit data to disk, and has had time to fix those bugs. Back in 2009, ext4 hadn't had time to fix some of those same data loss bugs that it inherited when it started being ext3-pretending-to-be-XFS; today, of course, much of that has gone. Argument 1: Why use pretend XFS? Really, ext4 was designed for two things: Semi-compatibility with ext3 (easy upgrade path, re-use of file system tools like tune2fs and debugfs and fsck) and pretending to be XFS. ext4's killer features are extents--which break the ability to mount ext4 as ext3 anymore--and the ability to convert to a lesser ext4 (without extents) by mounting ext3 as ext4. ext4 also has better performance because it added "delayed allocation": it allocates "space" instead of "specific blocks" until it's ready to flush, and so it knows that 500 blocks will be in use but hasn't committed to WHICH 500 until it flushes--a feature XFS has had forever. New installations given ext4 will be non-compatible with ext3 and ext2. They won't need an upgrade path. Thus there is no strong argument for ext4. There's also not much of an argument AGAINST ext4. Yes, XFS is more mature; but ext4 is plenty mature by now, or the kernel developers are woefully and terminally too stupid to be allowed to write code--face it, ext4 has had a LOT of attention and should be at least as mature as any other file system implementation in Linux if not more so. That doesn't mean it doesn't have bugs; just that we can't ascribe any such bugs to it being too young and/or too much of a fringe FS (i.e. ReiserFS, JFS) to have had the attention needed to shape it into production quality. XFS and JFS both have one thing over ext4: dynamic inode allocation. This is of course a corner case feature, because who runs out of inodes? (I have once or twice). ext4 has something big over XFS though: you can shrink an ext4 partition, and nobody has done the legwork to make xfs shrinkable. Shrinking is a common case for people who want to get away from a filesystem--750GB used on 1TB, shrink the file system, create 250GB file system, copy 1/3 of the data, shrink the filesystem again, move the high partition down, grow it, copy more data in, shrink the file system again, create another filesystem, copy data into that, remove original file system and reformat as your target FS, move data into it, expand it, move data from the other FS into that, shrink the high FS, move it all the way right, expand the new FS, move the rest of the data over, remove the high FS, then fill the disk with the new FS. You can't do that with XFS, because you can't shrink XFS; you would have to use thin provisioning (dm-thinp) from the start. Then you could create a new file system in the same space as the old one, move some data into it, fstrim the old XFS, then move more data, repeat until all the data is moved, then drop the XFS provision. Nobody knows how to use thin provisioning, and it's ridiculous to manage; if a desktop wants to switch from one file system to another, they're more likely to resize and copy partitions repeatedly for 3 or 4 days, or use an external drive. Thus XFS not having shrink is big. Now if XFS had shrink, I would argue that XFS is probably better than chasing ext4 and zfs... er, btrfs... for the desktop; while btrfs is better for the server, or will be when it's production ready. I don't argue JFS because it's very little used, although IBM wrote it and we all know IBM is universally horrible at software so we could assume JFS doesn't work at all outside somebody's fantasy. As it stands, just a rant. I do like XFS over ext4, but btrfs looks like it's bringing in a bunch more features as a filesystem that XFS doesn't/won't have (i.e. built-in compression!). The discussion over the merits of abandoning the "traditional" Linux filesystems (that being whatever the flavor of the week Linux-specific filesystem that the kernel devs are so proud of is) would be interesting, but I expect the technical merits to either wash out or lean against ... well, okay, the technical merits will probably lean against everything--if you really think about it, ext4 and btrfs are as bad as XFS and JFS, and why aren't we using UFS like BSD (or why isn't BSD using an implementation of XFS, ZFS, btrfs, ext4, or whatever's so great?) The whole thing seems to come down to "old generation" and "new generation" file systems, the same argument as we had when reiserfs suddenly became the most popular file system due to sub-block allocation and journaling. ext4 doesn't have block suballocation, but btrfs will. XFS doesn't either. In-place transparent compression and block suballocation are the killer features here. I'm not sure about btrfs being a log structure file system, but it looks interesting. Time will tell. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss