2

After reading up on the whole data=ordered fiasco that EXT4 went through and how much support there was on it accommodating "broken" applications, I was surprised that a filesystem that is not guaranteed to write the data before the metadata was chosen as the default in an enterprise linux OS.

https://www.suse.com/communities/conversations/xfs-the-file-system-of-choice/

Has XFS changed to the point where it is on par with the reliability of EXT4 in data=ordered mode or has some other variables changed where this is now a moot point?

Thomas Lynema
  • 31
  • 1
  • 1
  • 2

2 Answers2

3

Yes, XFS is basically on data=writeback modus operandi. EXT4 is the same, and so NTFS and BTRFS and any modern filesystem.

However, the common "wrong cases" (eg: crash/power loss when truncating a file) are all worked around in the code, so in practice EXT4 and XFS are very stable.

On the other side, many distributions used EXT3 without barriers, which in the wrong situation (eg: powerloss during a journal wrap-around) can totally destroy your filesystem.

In short: XFS is perfectly stable in production scenario, especially on RHEL (and derived) OS where is has many patches and backports from recent kernel releases. For example, while Debian 6.0 XFS performances were quite poor, RHEL 6 was much faster thanks to the delayed logging algorithm implemented in newer kernels and back-ported to RHEL one.

shodanshok
  • 47,711
  • 7
  • 111
  • 180
  • The default mode for EXT4 is data=ordered. I would say that makes it different than the others. And, yes, I agree that a application can be coded in a way to make data=writeback a stable option. – Thomas Lynema Apr 02 '15 at 18:03
  • 1
    EXT4 delayed allocation feature significantly alters the default data=ordered behavior, so it is more comparable to EXT3 + write back than "normal" ordered behavior. The workarounds defined above are **not** coded inside applications, rather they are embedded in the VFS/XFS kernel layers. In other words, they provide a safe (and slightly slower) environments even for not FS aware applications. – shodanshok Apr 02 '15 at 18:39
  • 1
    It looks like delayed allocation is suspended in some cases. From https://en.wikipedia.org/wiki/Ext4#Delayed_allocation_and_potential_data_loss . In response, ext4 in Linux kernels 2.6.30 and newer detect the occurrence of these common cases and force the files to be allocated immediately. For a small cost in performance, this provides semantics similar to ext3 ordered mode and increases the chance that either version of the file will survive the crash. This new behavior is enabled by default, but can be disabled with the "noauto_da_alloc" mount option – Thomas Lynema Apr 02 '15 at 18:50
  • Yes. This all happen at the VFS/XFS layer, as stated above. – shodanshok Apr 02 '15 at 20:19
  • 1
    This was not always the case. A change was made the filesystem layer in EXT4 to handle "broken" userspace apps. EXT4 added and defaulted to data=ordered. This change has this effect: `data=ordered (*) All data are forced directly out to the main file system prior to its metadata being committed to the journal.` Was there a similar change in XFS? – Thomas Lynema Apr 02 '15 at 20:42
  • 2
    [Yes](http://xfs.org/index.php/XFS_FAQ#Q:_Why_do_I_see_binary_NULLS_in_some_files_after_recovery_when_I_unplugged_the_power.3F). Please note that EXT4's workaround set is probably more complete, but XFS is very reliable indeed. – shodanshok Apr 02 '15 at 21:26
1

XFS uses the same workaround for "broken" applications that ext4 does. As already mentioned, ext4's "ordered" mode is basically the old ext3 "writeback" mode, with a little extra privacy thrown in. Both have have checksummed logs. Both have checksummed metadata. Both are "enterprise". Red Hat supports ext4 up to 50TB, and XFS up to 500TB. XFS might handle parallelization better on RAID. But I've always found ext4 to beat XFS for performance. For example, on a server I support which has a 6 15k drive RAID 10 array. I've never observed XFS's widely claimed performance advantage over ext4 for parallelism in any of my testing. Both filesystems are rock solid. ext4 is more flexible in that you can shrink it. XFS filesystems can only be grown. A damaged ext4 filesystem might be more effectively recovered by fsck.ext4 than a damaged XFS fs by xfs_repair because of all the static vs dynamic allocation ext4 does. ext4.fsck knows exactly where everything should be. XFS can't know for sure on its dynamically allocated structures.

Steve Bergman
  • 11
  • 2