Last night I decided to dump Debian testing for Arch yet again and on a whim I used I used xfs. The entire system seems faster with xfs than it did with either ext4 or btrfs I think it's probably just placebo but that's my initial impression. What is it I lose or better what are the benefits of the other common file systems. I know and have used the snapshot function of butter but outside that specific system why use the other common FS's?

xfs faster than BTRFS? I'd find that unsurprising (but that's not a measurement). xfs faster than ext4? I'd have expected that to be true (depending on use case, set-up, blah-di-blah), but not to the extent that you'd immediately notice, outside of benchmarking.

I'm not doubting that there are, under some circumstances, noticeable differences, but I'd have expected between ext4 and XFS it to be give and take on different specific tests, and that, overall, they'd have been near enough.

All that said, you'd have to also have a look at the scheduler and the way journalling was set up, because they can make similar levels of performance difference. Just as an example, back in the day, I used to feel that I could tell whether 'noatime' was set on a box, just by the 'feel' (speed) in casual use. Nowadays, I think practically every distro sets either 'noatime' or 'relatime' as their default, so that speed up tweak has passed its 'sell-by' date.

XFS is much more fragile (compared to EXTx) when it comes to power outages. This is the price you pay for speed. All my boxes with XFS have battery backups for this very reason.

In my experience XFS is noticably faster than ext4, especially for things like file listing, file searching, disk usage checks, etc. I've done benchmarks between the two of them and posted them on this forum before, it's more than an order of magnitude difference (close to two orders of magnitude IIRC).

THAT SAID - XFS is not very secure in my experience. I have encountered no less than THREE different systems, running two different distros, which encountered a sudden power failure that rendered the entire XFS filesystem corrupt beyond repair. In all three cases I had to completely reinstall the distro and restore from backup. Meanwhile I've encountered literally hundreds of power failures on ext4 systems, and have never encountered any corruption in the filesystem as a result.

The journaling in XFS is all but useless in my experience, I don't use it anymore.

Also remember "power failure" is from the perspective of the filesystem/drive, not necessarily the wall outlet. In one of those three cases I mentioned, the system simply locked up (rare, but it happens). I tried a few things to get access, but it was completely frozen. I held the power button down for a few seconds to shut off the machine, and when it booted back up the XFS filesystem was corrupt beyond repair and I had to reinstall the entire system. Needless to say, when I reinstalled I chose ext4 instead of XFS...

I just copied my music and the like back to the computer and that was noticeably faster. If it becomes corrupt I'll just reinstall but right now I'm liking this FS.

I've never really benchmarked or used many extensively from ext* but keep in mind if your comparing the two, you were in a completely different distro...

Recent filesystem benchmarks on an SSD (article also contains a link to the same benchmark on mechanical disks): http://www.phoronix.com/scan.php?pag...x-43-ssd&num=1

I personally switched from JFS and ext4 to BTRFS on all my systems, for me the offered functionality (especially subvolumes and snapshots) outweigh the (for me not noticeable) performance impact.

Big name linux company has moved enterprise to XFS.
If that means anything.

I don't us any f/s exclusively, but I have been on the bandwagon of btrfs for years - for the same reasons as above.
I did once accidentally use XFS (CentOS 7 default) - then needed to shrink it. Damn. Strike XFS.

When i see something being faster than expected, i immediately think: Why is it faster? What is it that it's not doing?

For root fs i have found reiserfs to be perfectly bulletproof. I haven't had a single headache with it for as long as it has been version 3.6.

EXT3 and EXT4 has given me some hassle. EXT3 can potentially fail real bad. But it is not at all common.

EXT4 is very much comparable to reiserfs36, but it is about 10% to 15% faster in general. And reiserfs loose the speed competition on deleting files.


Looking at "high end" filesystems like btrfs and zfs, they have one really good aspect. They checksum all the data, and use "copy on write" that will not simply overwrite file data, but rather rewrite a new copy somewhere else on the disk before marking the previous version as deleted. They also keep track on the health of the drive(s) used, and can to a certain degree save the day simply by avoiding to write the data "into a black hole" when a drive is failing out.
They also keep backups of the file metadata, so that even a striped raid with a broken drive in it will be able to tell what files are on it, and exactly where the file extents is supposed to be stored.
Instead of getting an unintelligible cluster salad, we get a partial restore with confidence of the extents checksums and the duplicated file metadata, and the fact that the fs with high probability will have retained the previous state of the file that just got rewritten to a bad sector.

So filesystems like btrfs and zfs are very robust. Also reiserfs and ext4 give some robustness due to the ordered journalling.

I had one server that crashed/rebooted cyclic over a night because of memory failure. After fixing the problem it booted up into an extensive journal recovery of all the reiserfs volumes in the lvm volume groups. After which everything was fine. Checked it to the latest backups. No problems.

So, there is a price on having a very fast filesystem. It is taking shortcuts with your data.


Concerning btrfs as a root fs - Don't!
Not just yet, at least. It is still under development, and is not a "production filesystem". Yet.
Best recommendation is to have a smaller root fs of type EXT4 or reiserfs running on a mirror, or raid10, and then use btrfs as a pure data pool. Less issues with booting, and the system will boot faster. And if you need to do maintenance of the larger btrfs filesystem, you can do this "in system", since everything needed for a full boot is in the smaller root fs. Also, when raid rebuilds on a root fs everything stumbles to a crawl. A small root fs rebuilds fast. And the base system will be responsive even if there is a day or two to rebuild raid for the larger data share fs.

While we are at it - ZFS will deteriorate in read/write speed when it becomes filled above 80%.
It may be of interest to know that the same goes for BTRFS. Both suffer performance penalties because of heavy fragmentation when filled above 80%. The difference being that BTRFS can be defragmented, while it may prove to be impossible to implement defragmentation on ZFS. It has been requested for a long time. But it seems to require a thorough redesign of ZFS.

1 members found this post helpful.

OK I just figured out a reason to not like xfs. Growing a partition is not a drag apply affair it's a bit more involved and I'm going to have to google it a couple more times before it'll absorb in my thick skull

I started using btrfs everywhere now. As always with real time propriety plus regular backups...

XFS has been used for many decades. I still have a few IRIX running some very old XFS. 90's

Red Hat has been promoting XFS (with many updates) on industrial and commercial applications. It can't be that bad for your home. A few more tools will bring you options for grow and shrink I'd think soon.

As to the speed there is no way to tell. There are millions of components and firmware that make up your computer. It could be that a well tested slower FS will or could run faster on your system.

I try to use a few of the major file systems just to keep things up to date.

I just had my first linux file system corruption today, xfs_repair fixed it but I've been on edge all day hoping I didn't have to reinstall since my clone is at my work apartment.