Linux file-systems index

Linux logo


BTRFS

[2015...2023/09]

This author has an overall positive opinion of BTRFS from experiences since 2015.

Positives:

  • BTRFS has never lost data AFAICT (except the one minor incident described below).
  • BTRFS has always kept its integrity, has never FUBARed itself.
  • BTRFS has proved itself robust, has survived many I/O errors and storage hardware failures.
  • BTRFS is the only Linux file-system that checksums files (other than ZFS).

Negatives:

  • BTRFS mismanages free space, requires manually running btrfs balance which sometimes fails.
  • Encountered a few minor bugs.

In situation where solid-state storage degraded to read-only after depleting write-capacity, BTRFS tolerated the failure, every file could still be read. In same situation, SGI XFS became FUBAR. Probably why BTRFS survived, but XFS failed, is BTRFS keeps duplicates of its meta-data (DUP). The case involving BTRFS was a SanDisk SDCARD that was written continuously 5 years, then its first error occurred -- write-capacity depleted. BTRFS immediately noticed the moment when SDCARD failed while BTRFS was computing and verifying checksums, so BTRFS turned itself read-only (coincident to SDCARD becoming read-only). This error surfaced up to cp command which printed error message that device was read-only (very probably reported from BTRFS, not SDCARD/driver). But after reboot, neither Linux-4.19 kernel nor BTRFS noticed the failed status of SDCARD, which allowed SDCARD to be mounted read-write. Then what was unreal was the false appearance of writing to SDCARD. Could seem to write files, but after unmounting, all changes disappeared! Ran write-then-read test using badblocks which proved, in reality, not one block could be written.

Once had a Seagate 3TB external/spinning disk-drive that began gradually failing. First one block became corrupted, then more and more. BTRFS RAID1 mirror worked magnificently, automatically correcting errors, until nearly every block became corrupted. 

[271438.585615] sd 13:0:0:0: [sdh]  
[271438.585619] Sense Key : Medium Error [current] 
[271438.585626] sd 13:0:0:0: [sdh]  
[271438.585632] Add. Sense: Unrecovered read error
[...]
[271438.585658] end_request: critical medium error, dev sdh, sector 3833558744
[271440.826457] repair_io_failure: 22 callbacks suppressed
[271440.826471] BTRFS: read error corrected: ino 294020 off 2469888 (dev /_dev_/_sdh2_ sector 903292184)
[271441.397876] BTRFS: read error corrected: ino 294020 off 2461696 (dev /_dev_/_sdh2_ sector 903292168)
[271441.511085] BTRFS: read error corrected: ino 294020 off 2473984 (dev /_dev_/_sdh2_ sector 903292192)

Example of a silly bug in BTRFS. All space was free on a newly formatted usbmem, but cp command hit a false out-of-space error. 

No space left on device
[404106.329079] BTRFS: open_ctree failed
cache and super generation don't match, space cache will be invalidated
Warning: fs/btrfs/ctree.h:1559
kernel: [332521.602856] Call Trace:
kernel: [332521.602863]  ? btrfs_remove_chunk+0x322/0x770
kernel: [332521.602868]  ? btrfs_relocate_chunk+0x9c/0xd0
kernel: [332521.602872]  ? btrfs_balance+0x91d/0x12c0

XFS

[2020/10...2023/07]

*** AVOID XFS -- XFS is FRAGILE. ***

XFS is fragile. If I/O error ever occurs on underlying storage, XFS might become FUBARed.

However, while underlying storage remains OK, XFS should be reliable and fast.

XFS deficiencies are no robustness, no fault-tolerance, no checksums for files, no compression.

An underlying I/O error (USB disconnect apparently) occurred while running diff -r. That's only a read-operation. All writes had completed. Yet XFS became damaged. XFS log became damaged. Required running xfs_repair -L (equivalent to running fsck like EXT2/UFS, defeating purpose of being a log/journal) and received scary warning that corruption might result.

Conclusion: XFS is fragile.
This author shall reformat over XFS with a more robust file-system (BTRFS or ZFS).
This author, based on experience, considers BTRFS more robust than XFS.

Evidently the design of XFS meta-data is not robust nor fault-tolerant. In one case, when the first error happened, XFS became FUBAR. XFS refused to mount a usbmem that had degraded to read-only after apparently depleting write-capacity. (Did not try trick of using dd to copy to another usbmem then trying xfs_repair.) To compare with BTRFS, in another case of write-capacity depletion, BTRFS proved itself robust, every file could still be read. 

[Thu Oct 13 08:48:21 2022] XFS (sdg1): Mounting V5 Filesystem
[Thu Oct 13 08:48:21 2022] XFS (sdg1): recovery required on read-only device.
[Thu Oct 13 08:48:21 2022] XFS (sdg1): write access unavailable, cannot proceed.
[Thu Oct 13 08:48:21 2022] XFS (sdg1): log mount/recovery failed: error -30
[Thu Oct 13 08:48:21 2022] XFS (sdg1): log mount failed

Haiku now [2022/09] has a read-only port of XFS. FreeBSD once had an experimental read-only port of XFS, but that was discarded.