Ntfs2btrfs does in-place conversion of NTFS filesystem to the open-source Btrfs

Original Article ↗ Hacker News Discussion ↗

Overview of ntfs2btrfs Approach and Risk

  • Tool performs in‑place NTFS → Btrfs conversion by:
    • Allocating a large file on the original FS for new Btrfs metadata.
    • Using extent mapping (e.g., fiemap-like behavior) so Btrfs data blocks mostly reuse existing NTFS data.
    • Overwriting the superblock only at the end, after content verification.
  • Similar approach to btrfs-convert (ext*→Btrfs), which can preserve old metadata as a rollback subvolume.
  • Several commenters still consider it “juggling chainsaws”: bugs have existed, including reports of corrupted or read‑only filesystems.
  • Strong advice from some: always have backups and prefer “backup → reformat → restore” over in‑place conversion for important data.

WinBtrfs vs Linux Btrfs and Cross‑OS Use

  • WinBtrfs is an independent Windows driver implementing the same Btrfs on‑disk format used by Linux.
  • Intended use cases include dual‑boot machines where Windows reads Linux Btrfs partitions.
  • Some confusion arose about metadata differences and NTFS alternate streams, but consensus is that it’s the same filesystem format with OS‑specific extensions via xattrs.

Why Convert NTFS to Btrfs?

  • Suggested reasons:
    • Single Btrfs partition with subvolumes for both Windows (via WinBtrfs) and Linux, rather than a separate NTFS partition.
    • Access to Btrfs features: snapshots, CoW, checksumming, compression.
  • Counterpoint: NTFS is seen by some as faster, stable, and “good enough,” already readable from Linux.
  • Others argue software can be written “for fun, learning, or proving it’s possible,” not only for performance or features.

NTFS Capabilities Clarified

  • Misconception: “NTFS has no case sensitivity or compression.”
  • Clarifications:
    • NTFS supports case‑sensitive directories/paths, but it’s rarely enabled and can break existing Windows software.
    • NTFS supports per‑file and per‑directory compression and newer LZ‑based algorithms, though often awkward to use in practice.

Btrfs Stability and Real‑World Experiences

  • Strongly mixed experiences:
    • Many report years of trouble‑free use on desktops, NASes, and backups, especially with snapshots, send/receive, and RAID1/10.
    • Others report:
      • Silent corruption (files or sectors becoming zeroed).
      • Catastrophic failures after power loss or running out of space.
      • Filesystems going read‑only or unmountable.
  • Parity RAID (5/6) is widely described as unsafe/unfinished; most recommend avoiding it.
  • Tools:
    • btrfs check/btrfs repair are explicitly documented as dangerous; recommended only under expert guidance.
  • Debate:
    • Pro‑Btrfs side stresses large production deployments and acceptable reliability if you avoid fragile features and keep backups.
    • Skeptical side cites repeated data‑loss anecdotes, incomplete design areas, and the need for filesystems to be exceptionally reliable.

Comparisons to Other Filesystem Conversions

  • Historical precedents:
    • Windows FAT→NTFS in‑place conversion (Windows 2000/XP).
    • Earlier FAT16→FAT32 conversions.
    • Apple’s HFS+→APFS live conversion across huge iOS/macOS fleets, with staged rollouts and pre‑deployment dry‑runs.
  • These show that in‑place conversion can work at scale, but requires extensive engineering and carries residual risk.