Checksums Won: Btrfs, bcachefs, OpenZFS, XFS, NTFS and ReFS in Late 2026
Versions current as of 25 September 2026. Benchmark figures come from real hardware runs published by modern-fs-benchmark.
For twenty years the filesystem argument has been framed as a speed contest. Pick a benchmark, run fio on a single disk with default options, crown a winner. That framing was always a little dishonest, because the thing modern filesystems were built for — telling you the truth about your data — never showed up in the charts.
This year that finally changed. Bartosz Fenski’s modern-fs-benchmark measures what copy-on-write filesystems are actually deployed for: redundancy layouts, snapshot aging, compression, reflinks, fsync tail latency, rebuilds after a dead disk, full filesystems and, crucially, what happens when a disk quietly starts returning garbage. Its real-hardware runs — on NVMe, on SAS hard drives and on a tiered SSD+HDD box — arrive in a year that has been unusually eventful for storage on both Linux and Windows.
Consider the backdrop. bcachefs left the mainline kernel in 6.18, now ships as a DKMS module and, in June, dropped its experimental label. Btrfs spent Linux 7.2 and 7.3 on the performance work its critics have demanded for years. OpenZFS 2.4 can put its intent log on special vdevs and added default quotas, with AnyRAID pencilled in for 2.5. XFS gained an autonomous self-healing daemon. Linux got a new NTFS driver — Linus Torvalds called it the “ntfs resurrection” — and Microsoft finally let Windows Server boot from ReFS, if only in preview.
The point is data integrity, not the winner’s podium.
— modern-fs-benchmark README
The headline finding fits in a sentence: checksums won. On the benchmark’s hard-drive array, every checksumming filesystem kept its test file intact after silent corruption, while XFS and ext4 on ordinary md and LVM RAID handed back corrupted data with a zero exit code — every single time. And the “checksum tax” people worry about mostly isn’t one: on HDDs, ZFS and bcachefs did three to thirteen times the fsync’d random writes of XFS and btrfs.
What is left to argue about is the edges: snapshot costs, latency under pressure, tuning traps, licensing and politics — and, on Windows, a vendor that ships its integrity-first filesystem with one hand tied behind its back. That is what the rest of this piece is about.
In this post:
- At a glance: the comparison table
- The benchmarks, analysed
- Filesystem by filesystem: pros, cons and verdicts
- Picks by use case
- Sources
A note on method. The benchmark dashboard is a script-driven page, so the numbers below are medians computed from the raw result files in the project’s results branches (three runs per hardware setup); they can differ slightly from the dashboard’s own charts. NTFS and ReFS are not part of the benchmark, which only tests Linux filesystems. Where this post says something about how they would behave under corruption, that is an inference from their design, and it is marked as such.
1. At a glance
| Btrfs | bcachefs | OpenZFS | XFS | NTFS | ReFS | |
|---|---|---|---|---|---|---|
| Latest version | Linux 7.2 (7.3 at rc4); btrfs-progs 7.1 | 1.39.6 (tools + DKMS module) | 2.4.4 (2.3.9 still maintained) | Linux 7.2; xfsprogs 7.2.0 | On-disk v3.1; Linux: new ntfs driver (7.1+), ntfs3, ntfs-3g 2026.9.18 | 3.14 (Windows 11 24H2+, Server 2025) |
| License / delivery | GPLv2, built into the kernel | GPLv2, DKMS module only (kernel 6.16+) | CDDL; separate module on Linux, built into FreeBSD | GPLv2, built into the kernel | Proprietary; Linux has kernel drivers + FUSE | Proprietary; Windows only |
| Maturity | Stable, except RAID5/6 | Declared stable by its developer (Jun 2026) | Very mature | Very mature | Very mature | Mature in its niches (Hyper-V, Storage Spaces Direct, backup) |
| Design | Copy-on-write B-trees | Copy-on-write, one shared b-tree layer | Copy-on-write + own volume manager | Metadata journal, extents | Metadata journal, MFT | Copy-on-write B+ trees |
| Checksums | Data + metadata | Data + metadata | Data + metadata | Metadata only | None1 | Metadata always; data optional (integrity streams) |
| Repairs bad data from redundancy | Yes (DUP/RAID1/10/56) | Yes (replicas / erasure coding) | Yes | No (metadata repair only) | No (metadata repair only) | Yes, with a Storage Spaces mirror or parity |
| Compression | zlib, lzo, zstd | lz4, gzip, zstd | lz4, zstd, gzip | None | LZNT1, WOF | LZ4/zstd after the fact (Server 2025) |
| Encryption | None (use LUKS; fscrypt in progress) | ChaCha20-Poly1305 | AES-256-GCM, per dataset | None (use LUKS) | EFS; BitLocker | BitLocker; EFS (3.14) |
| Snapshots | Subvolume snapshots, send/receive | Subvolume snapshots | Snapshots, clones, send/receive | None (use LVM) | None (Windows VSS) | Per-file (Server 2022+); VSS |
| Reflink / dedup | Reflink; after-the-fact dedup | Reflink | Block cloning; inline dedup | Reflink; after-the-fact dedup | None2 | Block clone; native ReFS dedup (Server 2025) |
| RAID / pooling | 0/1/1C3/1C4/10; 5/6 unstable | Replicas, erasure coding | Mirror, RAIDZ1–3, dRAID | None (use md/LVM) | None (use Storage Spaces) | Through Storage Spaces / S2D |
| Tiering | No | Built in | ARC, L2ARC, SLOG, special vdev | No | No | Mirror-accelerated parity (S2D only) |
| Resize | Grow and shrink | Grow; add/remove devices | Grow; limited device removal | Grow only | Grow and shrink | Grow only |
| Check / repair | Online scrub; offline check | Online and offline fsck | Online scrub, no fsck | xfs_scrub, xfs_healer, xfs_repair | chkdsk, online | Online repair, background scrubber, no chkdsk |
| Max file / volume | 16 EiB / 16 EiB | 16 EiB / 16 EiB | 16 EiB / 2128 bytes | 8 EiB / 8 EiB | 8 PB / 8 PB | 35 PB / 35 PB |
| Can hold the OS | Yes | Yes (depends on distro) | Yes | Yes | Yes | Preview only (Server vNext) |
| In the benchmark | Yes | Yes | Yes | Yes | No | No |
2. The benchmarks, analysed
modern-fs-benchmark tests redundancy layouts, snapshot aging, compression, reflinks, fsync tail latency, rebuilds, injected corruption and full disks, with ext4 as the classic baseline. Besides 618 CI runs on GitHub-hosted VMs, it has three real-hardware setups, each run three times:
- NVMe (July 2026): kernel 6.18.39, bcachefs 1.38.8, ZFS 2.4.3, btrfs-progs 7.0. The “4-device” arrays are four partitions spread over only two NVMe drives.
- SAS HDD (September 2026, current versions): kernel 7.1.13, bcachefs 1.39.6, ZFS 2.4.4, btrfs-progs 7.1. Four 16 GiB partitions on four separate disks.
- Hybrid SSD+HDD (September 2026): eight HDDs plus SSDs. Btrfs sits on md-RAID10 with an SSD write-back cache (dm-cache); ZFS uses HDD mirrors, an SSD special vdev and an SSD read cache (L2ARC); bcachefs uses its own built-in tiering across three SSDs.
2a. Overall score
This recomputes the dashboard’s own summary score, which combines raw I/O, responsiveness and metadata speed. 100 is the median of all 26 setups on that hardware.
| Setup | NVMe | HDD |
|---|---|---|
| ZFS raidz1 | 122 | 146 |
| ZFS mirror | 122 | 139 |
| ZFS mirror, recordsize=8k | 112 | 159 |
| bcachefs, single disk | 97 | 132 |
| bcachefs, 2 replicas | 97 | 127 |
| XFS on md-raid10 | 92 | 114 |
| ext4 on md-raid10 (baseline) | 107 | 98 |
| Btrfs, single disk | 96 | 94 |
| XFS, single disk | 93 | 91 |
| Btrfs raid1 | 87 | 78 |
| bcachefs, erasure coding | 86 | 85 |
| XFS on LVM raid10 + dm-integrity | 40 | 51 |
2b. Head to head: two-copy layouts
Each cell shows NVMe / HDD.
| Metric | Btrfs raid1 | bcachefs, 2 replicas | ZFS mirror | XFS on md-raid10 |
|---|---|---|---|---|
| Sequential write, MiB/s | 1,069 / 205 | 3,574 / 333 | 3,025 / 325 | 3,580 / 380 |
| Sequential read, MiB/s | 4,258 / 225 | 6,585 / 410 | 5,032 / 496 | 5,902 / 450 |
| 4k write + fsync, IOPS | 2,009 / 156 | 2,709 / 920 | 8,797 / 1,222 | 2,002 / 306 |
| 4k random write, 16 threads, IOPS | 11,978 / 235 | 21,507 / 2,824 | 6,658 / 3,092 | 9,213 / 261 |
| 4k random read, 16 threads, IOPS | 337,814 / 1,646 | 85,780 / 1,046 | 132,798 / 8,698* | 368,180 / 1,613 |
| fsync p99 | 9.5 ms / 401 ms | 10.3 ms / 54 ms | 2.7 ms / 57 ms | 11.2 ms / 103 ms |
| Small-op p99 during a big streaming write | 44 ms / 7.1 s | 259 ms / 1.1 s | 33 ms / 1.7 s | 32 ms / 0.98 s |
| Create a snapshot | 24 / 80 ms | 61 / 106 ms | 713 ms / 2.1 s | n/a |
| Delete 500 snapshots | 0.09 s / 2.5 s | 21 s / 149 s | 1.1 s / 3.2 s | n/a |
| Overwrite speed kept as snapshots pile up | 116% / 91% (100 snapshots) | 96% / 87% (100) | 57% / 70% (10) | n/a |
| zstd compressed write, MiB/s | 872 / 399 | 910 / 242 | 2,296 / 689 | n/a |
| First overwrite of a fresh clone vs plain file, MiB/s | 332 vs 173 / 29 vs 25 | 165 vs 169 / 102 vs 84 | — / 0.7 vs 10.9 | 49 vs 448 / 16 vs 21 |
| Rebuild after losing a device | not measured† | 4 s / 32 s | 6 s / 52 s | 83 s / 84 s |
| Scrub | 1 s / 50 s | 8 s / 66 s | 6 s / 59 s | 167 s / 167 s |
| Test file intact after injected corruption | 3/3 / 3/3 | 3/3 / 3/3 | 3/3 / 3/3 | 3/3‡ / 0/3 |
2c. Hybrid SSD + HDD tiering
| Metric | Btrfs on md-RAID10 + dm-cache | ZFS mirrors + special vdev + L2ARC | bcachefs built-in tiering |
|---|---|---|---|
| Sequential write / read, MiB/s | 453 / 1,144 | 691 / 698 | 883 / 1,431 |
| 4k write + fsync, IOPS (1 / 16 threads) | 406 / 7,169 | 8,869 / 115,214 | 4,328 / 9,120 |
| fsync p99 | 152 ms | 0.74 ms | 33 ms |
| 4k random read, IOPS (1 / 16 threads) | 7,609 / 111,078 | 236 / 10,557 | 294 / 9,800 |
| Overwrite speed after 32 snapshots | 18 MiB/s (98% kept) | 11 MiB/s (45% kept) | 108 MiB/s (101%) |
| Create a snapshot / delete 250 | 14 ms / 0.11 s | 3.4 s / 0.5 s | 134 ms / 28 s |
| zstd compressed write, MiB/s | 625 | 1,477 | 246 |
2d. What the data says
- Plain RAID returns bad data silently. Every copy-on-write layout kept the test file intact: 3/3 on each hardware set and 50/50 in CI. XFS and ext4 on plain md/LVM RAID served corrupted data with no error in 3 of 3 HDD runs (0/50 in CI for XFS on LVM). Adding dm-integrity fixes that, but cuts sequential writes by up to 97% (3,537 → 106 MiB/s on NVMe).
- On HDDs, copy-on-write filesystems that write like a log win random writes. ZFS and bcachefs did about 3–13× the fsync’d random writes of XFS and Btrfs.
- ZFS has the best sync-write latency. fsync p99 was 2.7 ms on NVMe. With an SSD special vdev holding its write log (new in 2.4), an HDD pool reached 0.74 ms.
- ZFS’s default 128K record size hurts small overwrites under snapshots. Speed drops 30–43% after only 10 snapshots, and overwriting a freshly block-cloned file ran 16–28× slower on HDD arrays (87× on the hybrid pool). Switching to 8k records fixes the aging, but NVMe sequential reads fall from 5,032 to 857 MiB/s.
- Neither real-hardware run includes Btrfs’s 7.2/7.3 performance work, so its slow NVMe writes and multi-second HDD stalls may improve.
- Don’t treat the dashboard’s CI ranking as a verdict. Loop devices on shared VMs reorder the results; ZFS mirror scores 69 in CI versus 122–139 on real hardware.
2e. Caveats
- Small test sizes: 16 GiB partitions (which make HDD seeks unusually short) and 2 GiB working sets.
- Few runs: three per hardware setup, so treat differences under about 20–30% as noise.
- Two tests only ran in CI: the full-disk test and the Btrfs device-loss test. The full-disk test used tiny 4×2 GB arrays, so Btrfs’s 0 MiB/s near-full result mostly reflects its 1 GiB allocation granularity.
- Real-hardware repair evidence is partial: ZFS reported zero scrub errors there, which suggests the injected overwrite missed its data (CI shows ZFS detecting and repairing errors every time), and the harness doesn’t parse bcachefs’s scrub counts.
3. Filesystem by filesystem
On Windows the split is stark: NTFS is the universal but unchecked default, and ReFS is the integrity option Microsoft keeps on a short leash. On Linux, the three copy-on-write filesystems are all good at integrity; they differ in where they pay for it.
OpenZFS: still the standard to beat
Pros
- Top overall score on both NVMe (122) and HDD (139–159), though its HDD read numbers are flattered by its cache.
- Best sync writes: fsync p99 of 2.7 ms on NVMe and about 4–13× the fsync’d random IOPS of Btrfs and XFS on HDD. An SSD special vdev gives sub-millisecond p99 on an HDD pool.
- The most complete integrity story: end-to-end checksums, RAIDZ/dRAID with no write hole, native encryption (including sending backups while still encrypted) and quick rebuilds — 4–6 s on NVMe and 42–59 s on HDD, versus 83–119 s for md.
- Fastest compression: 2.2–2.5 GB/s on NVMe and 560–850 MB/s on HDD, above raw disk speed.
Cons
- The license keeps it outside the Linux kernel, and support trails new kernels (2.4.4 stops at 7.2).
- The default 128K record size is wrong for small random overwrites with snapshots, and tuning it gives up sequential reads and compression.
- Creating a snapshot is slow (0.25–0.8 s on NVMe, 1.8–3.6 s on HDD), and block-cloned files are slow to overwrite on HDD.
- Rigid layout: RAIDZ devices can’t be removed, pools can’t shrink and mixed disk sizes waste space. AnyRAID, which fixes the last point, is planned for 2.5 but hasn’t shipped.
- Its cache wants RAM, and 16-thread NVMe random reads reach 133k IOPS against 330k+ for the others.
Verdict: the default choice for data you can’t lose, especially on HDD arrays. Tune datasets per workload.
Btrfs: excellent snapshots, weak under pressure
Pros
- Built into the kernel; the default on Fedora and openSUSE.
- The best snapshot and reflink performance measured: snapshots in 21–25 ms, 500 of them deleted in under 0.1 s on NVMe, 11 ms reflinks, and no slowdown when clones or aged snapshots are overwritten.
- Its checksums visibly work: scrub found and repaired 100% of injected errors in every redundant run.
- Near-XFS parallel reads (338k IOPS at 16 threads) and flexible mixed-size pools that can grow, shrink and change layout while online.
- Kernels 7.2 and 7.3 bring large performance improvements.
Cons
- Slowest sequential writer on NVMe: about 1.1 GB/s versus 3–3.7 GB/s for the others.
- Poor on HDD: fsync p99 of 401 ms and 7.1 s small-op stalls during a streaming write (16.5 s with LUKS). Its redundant layouts score lowest of the copy-on-write group (73–78).
- Single-stream reads don’t use both RAID1 copies: 225 MiB/s versus 410–496 for the others on HDD.
- RAID5/6 is still marked unstable; raid6 took 48 s to create 20k small files on HDD.
- No native encryption, so LUKS encrypts every copy separately. The btrfs check –repair man page says to use it only on a developer’s advice.
Verdict: great for Linux desktops, root filesystems and snapshot-heavy work on SSDs. Avoid parity RAID, and be careful on HDD arrays until 7.2/7.3 prove themselves.
bcachefs: the most ambitious design, held back by its politics
Pros
- Everything in one layer: checksums, compression, authenticated encryption, snapshots, replicas, erasure coding and tiering.
- The best non-ZFS showing on HDD (scores 127–132), with the best fsync p99 (25–54 ms).
- Encryption is almost free on HDD (128 vs 127 score); on NVMe it costs about 43% of sequential write speed.
- Fastest rebuilds (4 s on NVMe, 32 s on HDD). Overwrite speed stays at 85–100% as snapshots accumulate (erasure coding on HDD keeps only 61%).
- Real tiering: about 10× the fsync’d random writes of Btrfs + dm-cache in the hybrid test, and the top sequential speeds.
Cons
- Out of the mainline kernel since 6.18 after a dispute with kernel maintainers. It ships only as a DKMS module and has one lead developer.
- Deleting 500 snapshots takes 20 s on NVMe and 2.5 minutes on HDD, versus 0.1–3 s for Btrfs and ZFS.
- Weak parallel reads: 47k–86k IOPS at 16 threads on NVMe versus 330k+, and 250–490 ms small-op stalls during a streaming write on NVMe.
- Erasure coding is the weak layout: 137 MiB/s sequential writes on HDD and 2–4 MiB/s near-full writes in CI.
- Compressed writes are slower than the others (about 240 MiB/s on HDD).
Verdict: the most interesting Linux filesystem, and already close to ZFS on HDDs and tiered setups. Use it only if you are comfortable with DKMS and keep separate backups.
XFS: fast, protects its metadata, blind to data corruption
Pros
- Built into the kernel, very mature and the RHEL default.
- The NVMe speed reference: 3.7 GB/s sequential writes, 368k random reads and about 30 ms small-op latency during a streaming write.
- No copy-on-write overhead: plain 4k overwrites at 450–720 MiB/s on NVMe.
- Online metadata repair plus the new auto-repair daemon xfs_healer (7.0); zoned-device support is no longer experimental, and reflinks take 4–12 ms.
Cons
- No data checksums: on plain RAID it returned corrupted data silently in every HDD run. dm-integrity fixes that, but those setups score bottom (40–51).
- Snapshots, compression, encryption and pooling all need a stack of other tools. LVM snapshots were the worst performer in the benchmark: 2–11 MiB/s overwrites and 95–433 s to delete 150 snapshots.
- The first overwrite of a reflinked copy is 9–14× slower than a plain file on NVMe.
- Can only grow, not shrink. On HDD, fsync’d random writes reach 233–306 IOPS versus about 1,000 for ZFS and bcachefs.
Verdict: right for databases and bulk throughput when the application or the storage handles integrity. Not a safe place for irreplaceable data on its own.
NTFS: universal, frozen, no integrity checks
Pros
- Works everywhere Windows data needs to go.
- Mature features: ACLs, quotas, EFS, compression, reparse points and a change journal (USN).
- Online self-healing plus online chkdsk; volumes up to 8 PB.
- Linux 7.1’s new driver is a real step up: full read/write, fsck tools, and it passes 326 kernel filesystem tests versus 273 for ntfs3.
Cons
- No checksums and no copy-on-write. The benchmark’s silent-corruption scenario is exactly what NTFS can’t detect (inferred from its design; NTFS wasn’t tested).
- No native snapshots — Windows “Previous Versions” only works on volumes up to 64 TB — and no built-in RAID.
- The on-disk format hasn’t changed since Windows XP.
- Messy on Linux: two competing kernel drivers, desktop auto-mounting still picks the older ntfs3, volumes left by Windows Fast Startup or hibernation are marked dirty, and ntfs-3g had 9 CVEs fixed in July 2026 and 8 more memory-safety fixes in September.
Verdict: use it to exchange data with Windows, not as the only copy of anything important.
ReFS: Microsoft’s answer to ZFS, still on a leash
Pros
- Copy-on-write design with metadata checksums always on and optional data checksums; a background scrubber and online repair from Storage Spaces copies replace chkdsk.
- Block cloning makes creating or merging large VM disks take seconds; limits are 35 PB.
- A growing feature list: per-file snapshots (Server 2022), dedup plus LZ4/zstd compression (Server 2025), EFS encryption (3.14), Windows 11 Dev Drive, and booting from ReFS in the Server vNext preview.
Cons
- Windows-only and undocumented; Linux access only through a commercial driver.
- Data checksums are opt-in, and repair needs Storage Spaces redundancy. On a single disk, a corrupt file is removed rather than fixed.
- Still missing NTFS basics: it can’t boot Windows outside the preview, and has no shrink, quotas, transactions or removable-media support. Most Windows editions can’t create ReFS volumes, apart from Dev Drive.
- Windows silently upgrades ReFS volumes to its newer on-disk version, which can make them unreadable on older Windows.
Verdict: the right choice for Hyper-V, Storage Spaces Direct and backup repositories on Windows Server. Elsewhere on Windows, NTFS stays the default until ReFS boot ships.
4. Picks by use case
| Use | Pick |
|---|---|
| HDD NAS or server | OpenZFS (mirrors or RAIDZ; tune recordsize; add a special vdev for sync-heavy work) |
| Linux desktop or root filesystem | Btrfs |
| SSD + HDD tiered box, willing to experiment | bcachefs with backups, or ZFS with a special vdev |
| Databases or maximum NVMe throughput | XFS, with integrity handled by the application or replication |
| Windows client, dual-boot, USB drives | NTFS |
| Windows Server VMs and backup | ReFS on Storage Spaces |
Thanks to Bartosz Fenski for building and publishing modern-fs-benchmark, raw data included. If you have hardware to spare, the project is looking for more of it.
5. Sources
- Benchmark: dashboards — main (CI), NVMe, SAS HDD, hybrid; raw data: https://github.com/fenio/modern-fs-benchmark (branches results-real-hw*, results-data); discussion with the author: Hacker News.
- Btrfs: status page, Linux 7.2 changes, Linux 7.3 Btrfs pull (Phoronix).
- bcachefs: bcachefs.org, The Register on 1.38.6.
- OpenZFS: release notes, zpool-remove(8).
- XFS: xfsprogs releases, Linux 7.0 changes.
- NTFS: Microsoft NTFS overview, new Linux driver (Linuxiac), ArchWiki, ntfs-3g CVEs (oss-security), ntfs-3g 2026.9.18 (Phoronix).
- ReFS: Microsoft ReFS overview, Wikipedia, ReFS boot (4sysops), ReFS in Server 2025 (StarWind).
Filed under: BTRFS - @ 25/09/2026 10:48