Bug hunting in Btrfs

Original Article ↗ Hacker News Discussion ↗

Btrfs’ reliability and future on Linux draw sharply mixed views, especially as alternatives like ZFS and the newly merged Bcachefs mature. Commenters trade experiences ranging from long-term, trouble-free use with powerful snapshot tooling to repeated, irrecoverable data corruption and weak recovery utilities, with particular concern over RAID5/6 safety and obscure bugs. Licensing constraints around ZFS, the relative immaturity of Bcachefs, and the critical role of filesystems in everything from laptops to multi-petabyte storage clusters all feed into a broader question of whether Btrfs is “good enough” today or still too risky outside carefully constrained use cases.

Future of Btrfs vs ZFS/Bcachefs

  • Some expect Btrfs to have a long future, especially given ZFS licensing complications and the immaturity of Bcachefs features like erasure coding and scrub.
  • Others think Bcachefs will eventually replace Btrfs, but note this is “many years off.”
  • Bcachefs is seen as having fewer historical missteps, but it still lacks critical functionality and real‑world exposure.

ZFS Licensing and Legal Risk

  • Debate over whether GPL/CDDL incompatibility truly forbids shipping ZFS with Linux; some cite OpenZFS’ view that binary modules are fine.
  • Counterpoint: legal theory matters less than Oracle’s potential to cause costly trouble; conservative distros may reasonably avoid the risk.
  • Ubuntu’s long‑standing ZFS module without Oracle action is cited as evidence the risk is low, but not zero.

Reliability and Corruption Experiences

  • Several users report repeated, sometimes unrecoverable Btrfs corruption on consumer hardware, contrasting it unfavorably with ext4.
  • Others report decade‑plus stable use, including multi‑disk RAID1 and long‑running systems, sometimes surviving hardware faults with manual repair.
  • Consensus: Btrfs has sharp edges; some workloads and misconfigurations (bad RAM, RAID5/6, quotas) are risky.

Performance, Background Work, and Quotas

  • Reports of Btrfs “cleaner” / background threads consuming high CPU on low‑end systems, making them feel unusable, especially with openSUSE defaults (snapshots + quotas).
  • Disabling quotas often alleviates problems; snapshot deletion with quotas is noted as particularly expensive.

Known Problem Areas and Bugs

  • RAID5/6 is widely acknowledged as unsafe; official docs and tools discourage it.
  • A reproducible bug is described when converting nearly‑full ext3 to Btrfs and then defragging with compression; can lead to unfixable “out of space.”
  • Discussion that filesystems are critical infrastructure; some view “don’t use feature X” as unacceptable for production software.
  • The linked article’s race condition bug is considered very rare in practice, but sparks debate about what sample sizes (e.g., 100 machine‑hours) actually prove.

Use Cases and Alternatives

  • Many choose ext4 or XFS for “rock solid” behavior and database workloads; XFS is said to be preferred by most databases.
  • Some run databases (PostgreSQL/MySQL replicas, RocksDB) on Btrfs or ZFS, often for compression and snapshotting, accepting CoW overhead.
  • NAS vendors like Synology use Btrfs mainly on top of classic RAID, avoiding Btrfs’ native RAID features.

Snapshots, Backups, and Tooling

  • Btrfs snapshots plus tools like snapper/btrbk are praised for easy rollback and fast backups, especially on rolling distros.
  • Some want Btrfs‑like snapshotting in WSL2; current workarounds involve LVM, dm‑snapshot, or future mechanisms like blksnap.

In‑Place Conversion and Expectations

  • In‑place ext→Btrfs conversion is viewed by some as inherently risky; others argue that if documented and supported, it should be reliable.
  • Broader point: for many, filesystems must be “format, mount, forget,” with bugs considered intolerable compared to application failures.