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
