Ntfs2btrfs does in-place conversion of NTFS filesystem to the open-source Btrfs
An open-source tool, ntfs2btrfs, can convert an NTFS filesystem in place to Btrfs (via the WinBtrfs driver), reusing existing data blocks and only rewriting metadata before finally switching the superblock. Commenters find the concept impressive but risky, repeatedly stressing that even carefully engineered in-place conversions are no substitute for verified backups and a clean reformat when data is important. The thread broadens into a debate over Btrfs’s real-world reliability versus alternatives like NTFS, ext4, XFS, and ZFS, with experiences ranging from years of trouble-free use to reports of corruption and tooling that remains complex or fragile in edge cases.
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 repairare 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.