EXT4 Gets Performance Work While XFS Gets 32-Bit Fixes For Linux 5.6

[phoronix]

Phoronix: EXT4 Gets Performance Work While XFS Gets 32-Bit Fixes For Linux 5.6

File-system / storage activity is as busy as always during the Linux kernel merge windows...

http://www.phoronix.com/scan.php?page=news_item&px=EXT4-XFS-IO-uring-Linux-5.6

[ssokolow]

Years ago, I remember reading that XFS dealt with unexpected power loss much less gracefully than EXT4, so I've always been wary of it. (It just feels like a fundamental design flaw to me for a filesystem to rely on never seeing sudden power loss or, one would assume, a kernel panic.)

Has that changed?

[RahulSundaram]

Years ago, I remember reading that XFS dealt with unexpected power loss much less gracefully than EXT4, so I've always been wary of it. (It just feels like a fundamental design flaw to me for a filesystem to rely on never seeing sudden power loss or, one would assume, a kernel panic.)

Has that changed?

It has been the default from RHEL 7 and xfs has a extensive test suite to check on such conditions for several years now

[stormcrow]

It has been the default from RHEL 7 and xfs has a extensive test suite to check on such conditions for several years now

That's true, the tools for recovery have improved considerably since the early days. They've also continued to improve since RH began to focus on XFS for its core storage products since they don't like BTRFS. That said, Ext4FS has employed a great deal of engineering over the years to work around all the broken (as in deviations from specs, buggy drive firmware, etc) storage I/O in consumer and enterprise hardware.

I have run into problems with Ubuntu and it's screwy support for non-default values in the installers. Ubuntu's grub-efi has um... "issues" with root on XFS at times that aren't in other distros. I've also seen some games that for some really screwy reason are very crashy with XFS but not on Ext4FS on the same hardware. They're probably making assumptions or doing things they shouldn't be at a guess. Game devs are notorious for doing things like that.

[ssokolow]

I've also seen some games that for some really screwy reason are very crashy with XFS but not on Ext4FS on the same hardware. They're probably making assumptions or doing things they shouldn't be at a guess. Game devs are notorious for doing things like that.

Thanks for reminding me about that. Apparently it has to do with 32-bit games that weren't compiled with Large File Support not liking multi-terabyte partitions and EXT4 having some kind of quirk that prevents the problem from showing up when the developers then test their creations on *buntu.

(In other words, yes. In the presence of large hard drives, they're assuming some implementation detail of EXT4.)

[Britoid]

Years ago, I remember reading that XFS dealt with unexpected power loss much less gracefully than EXT4, so I've always been wary of it. (It just feels like a fundamental design flaw to me for a filesystem to rely on never seeing sudden power loss or, one would assume, a kernel panic.)

Has that changed?

Yes, completely. XFS shouldn't be any less reliable now than ext4.

[uid313]

What type of software uses IO_uring?
Anyone can name any software that use IO_uring?

[RahulSundaram]

What type of software uses IO_uring?
Anyone can name any software that use IO_uring?

Various async libraries have open RFE's or pending PR's to support it

https://github.com/rust-lang/rust/issues/60589

https://github.com/libuv/libuv/issues/1947

[Ardje]

Years ago, I remember reading that XFS dealt with unexpected power loss much less gracefully than EXT4, so I've always been wary of it. (It just feels like a fundamental design flaw to me for a filesystem to rely on never seeing sudden power loss or, one would assume, a kernel panic.)

Has that changed?

I feel you man. I've tried about every filesystem, but of all filesystems, only ext4 had the least grieving bugs. XFS would panic on me, jfs would panic, btrfs would self corrupt and a fsck that takes over 6 months to complete with an out of memory error with 512GB swap space allocated.... reiserfs was the best filesystem in the 2.4 era, even in crash/power outage recovery. But then came 2.6 and it seems that reiser 3.6 combined with the 2.6 series was not reliable anymore. But reiser had so many important features so we kept at 2.4 and occassionally tried 2.6 series. The ext3 fs had some features that were better than ext2, almost closing the gap with reiser. But stability was more important, so the 32k directory limit was accepted until ext4 came.
The biggest problems we had with ext4 was with containers and low memory pressure where ext4 contained a lot of hard to hit bugs.
Even though btrfs was crap, we retried and retried, as the data was expandable up to a certain point. But the time gain we got using snapshots was very big. Yes, we solely used it as an online backup storage. Snapshot, rsync, delete older snapshot. Deleting an older snapshot on ext4 would take days of making the filesystem almost inaccessible (of every file in every directory it would per file decrement the link count and sync meta data), and on btrfs a few hours of background disk activity.
I think it took over 5 years before btrfs was in a state that it could handle that continously, instead of corrupt, wipe, start over.

[visualblind]

I feel you man. I've tried about every filesystem, but of all filesystems, only ext4 had the least grieving bugs. XFS would panic on me, jfs would panic, btrfs would self corrupt and a fsck that takes over 6 months to complete with an out of memory error with 512GB swap space allocated.... ]

#Ardje, you can't use swap with BTRFS, unless you used a very recent kernel if I remember correctly. Ask me how I know.