BTRFS-ism: The “Corrupt Leaf” Mystery – or when newer kernels turn strict
| Created | Modified

TL;DR if you are into a longer version including how to debug check BTRFS-ism: Metadata “Evolution” – the story so far!

If you’ve moved a BTRFS drive from an older system (like Ubuntu 20.04) to a cutting-edge kernel (like 6.15) and suddenly hit a “can’t read superblock” on mounting your volume, you aren’t alone. Even weirder: the drive still works perfectly on the old system.

$ sudo mount /dev/mapper/luks-5c3931a2-4333-415f-8e58-b3b4d728f4d8 /media/backup
mount: /media/backup: can't read superblock on /dev/mapper/luks-5c3931a2-4333-415f-8e58-b3b4d728f4d8.

It’s not clear where the error originates: it could mean you used a newer kernel with older btrfs-progs with your BTRFS FS.

The Symptom

The mount fails on the new system, and dmesg throws a cryptic error:

corrupt leaf: block=830717952 slot=86 extent bytenr=2327262031872 len=36864 invalid data ref objectid value 18446744073709551604

The Cause: Metadata “Evolution”

This isn’t actually hardware corruption. It’s a validation disagreement.

The massive number in the error (18446744073709551604) is a technical “wrap-around” value for internal Btrfs references. This usually happens when a filesystem is created or managed using older btrfs-progs (like v5.16) on a system that doesn’t quite align with modern kernel defaults.

Newer kernels (6.0+) have a much stricter Tree-Checker. While the older system ignores these non-standard metadata values, the newer kernel sees them, flags them as “invalid,” and refuses to mount the drive to prevent potential data loss.

Mitgation: Read-only Rescue Mount

You can mount skipping all modern checks – but only-do read-only or there be dragons!

[!WARNING]

By using rescue=all, you are telling the kernel: “Ignore the Tree-Checker.” The kernel will stop complaining about the invalid data ref objectid and allow the mount. However, because you are mounting in rw (read-write) mode, the kernel will attempt to update the metadata. If it writes new data based on a “leaf” it already thinks is weird, it could technically propagate that “weirdness” to other parts of the tree.

$ mount -t btrfs -o rescue=all,ro /dev/btrfs-volume /mnt/mountpoint

But note the messages DMESG:

[  +0.017638] BTRFS info (device dm-2 state CS): disabling log replay at mount time
[  +0.000004] BTRFS info (device dm-2 state CS): enabling disk space caching
[  +0.000001] BTRFS info (device dm-2 state CS): ignoring bad roots
[  +0.000001] BTRFS info (device dm-2 state CS): ignoring data csums
[  +0.000001] BTRFS info (device dm-2 state CS): ignoring meta csums
[  +0.000000] BTRFS info (device dm-2 state CS): ignoring unknown super block flags

The Fix: Rewrite Metadata

Since the old system can still read the drive, your data is safe. To bridge the gap:

On the old system which is able to mount, mount the volume and run a metadata balance:

$ mkdir /mnt/bad-drive
$ mount /dev/vda /mnt/bad-drive
$ btrfs balance status -mconvert=dup --bg /mnt/bad-drive
Done, had to relocated 13 out of 2816 chunks
$ watch -n1 btrfs balance status /mnt/bad-drive

You can use a VM to boot an older system via KVM and attach your block storage:

$ aria2c -j8 https://releases.ubuntu.com/focal/ubuntu-20.04.6-live-server-amd64.iso
$ sudo qemu-system-x86_64 \
  -enable-kvm \
  -m 2G \
  -cpu host \
  -cdrom ubuntu-20.04.6-live-server-amd64.iso \
  -drive file=/tmp/cloud-init-RLrcc/seed.iso,format=raw,media=cdrom \
  -drive file=/dev/mapper/btrfs-drive,format=raw,if=virtio \
  -boot d

This forces the kernel to rewrite the “leaves” in a way that often cleans up these legacy references.

Best: The “Clean Slate” (Best Practice)

But still following could happen on a simple write to the fixed (?) FS …

[  +0.000000] BTRFS error (device dm-2): block=6363830763520 write time tree block corruption detected
[  +0.010717] BTRFS: error (device dm-2) in btrfs_commit_transaction:2540: errno=-5 IO failure (Error while writing out transaction)
[  +0.000003] BTRFS info (device dm-2 state E): forced readonly
[  +0.000005] BTRFS warning (device dm-2 state E): Skipping commit of aborted transaction.
[  +0.000001] BTRFS error (device dm-2 state EA): Transaction aborted (error -5)
[  +0.000001] BTRFS: error (device dm-2 state EA) in cleanup_transaction:2027: errno=-5 IO failure

I hope it’s not just a rumour that BTRFS has now reached maturity with Linux 6.x or next 7.x .

BTRFS is forward-compatible and I usually trust kernel-developers. IMHO if you are moving to a modern kernel permanently, the safest bet is to back up your data, reformat the drive using the modern system’s tools, and move the data back. This ensures the filesystem structures are native to the newer, stricter standards.

BTRFS is evolving fast. Sometimes, the “corruption” is just a newer kernel being a more observant librarian than the old one.

Always keep a backup and decent snapshots when working with BTRFS.