r/btrfs

I moved a year ago from Windows to Linux and for my picture collection from Picasa to Immich.

My Linux is using btrfs on a 2TB nmve disk for /root and /home and a 4TB hdd to back up /home (using rsync). I put the pictures and Immich database on a dedicated user in /home but I'm already using too much data on the ssd:

https://preview.redd.it/t6z7hf5j5o1h1.png?width=2002&format=png&auto=webp&s=c5ab5d205d3372f1b52d2fe84553db7ce169ccb5

First it is not clear to me if I really use all that space. Is it caused by the snapshots? How can I confirm this?

sudo btrfs filesystem usage /home

https://preview.redd.it/pp61kmaa6o1h1.png?width=774&format=png&auto=webp&s=58510e8c4315cfcff9ca61a85e7378ae53f809ba

Should I buy another 4TB hdd (or 2TB) and put the picture collection on it and mount it in /srv?

Do you have any suggestions on how to organise the disk space?

I'm using btrfs in a RAID1 setup comprised of 2 nvme drives, 2TB each. One of the drives is mounted directly on the motherboard. The other is connected using a PCIe adapter card.

So I just updated my debian desktop system and restarted the computer. As the system rebooted itself, I noticed a console message BTRFS error along the lines of "error writing primary super block". So I crossed my fingers and hoped it would not be a serious problem. But of course, the system would not boot after that.

I assumed (incorrectly, as explained below) that it must have something to do with the debian update but couldn't find any similar reports online. So I rebooted using SystemRescue. Was fortunately able to mount one of the drives read-only and am currently backing up everything from the @home volume just in case things get worse.

Have not attempted to do anything with btrfs tools yet, because I want to understand the situation better before attempting to fix anything. But I was able to use journalctl -D to review the logs.

I was shocked to find a continuous stream of btrfs errors occurring since yesterday morning, long before the debian update. It seems to have begun during a resume from suspend. (I only recently enabled the suspend option in Gnome, figuring it would be good to reduce electricity when not using the computer.)

Any suggestions for safely fixing this and preventing it in the future?

Here are some of the journalctl messages. Will provide more if needed.

First btrfs errors from yesterday:

May 15 10:55:14 vader kernel: nvme nvme1: Device not ready; aborting initialisation, CSTS=0x0
May 15 10:55:14 vader kernel: nvme nvme1: Disabling device after reset failure: -19
May 15 10:55:14 vader kernel: BTRFS error (device nvme0n1p3): bdev /dev/nvme1n1p1 errs: wr 0, rd 1, flush 0, corrupt 0, gen 0
May 15 10:55:14 vader kernel: BTRFS error (device nvme0n1p3): bdev /dev/nvme1n1p1 errs: wr 0, rd 2, flush 0, corrupt 0, gen 0
May 15 10:55:14 vader kernel: BTRFS error (device nvme0n1p3): bdev /dev/nvme1n1p1 errs: wr 0, rd 4, flush 0, corrupt 0, gen 0
May 15 10:55:14 vader kernel: BTRFS error (device nvme0n1p3): bdev /dev/nvme1n1p1 errs: wr 0, rd 4, flush 0, corrupt 0, gen 0
May 15 10:55:14 vader kernel: BTRFS error (device nvme0n1p3): bdev /dev/nvme1n1p1 errs: wr 1, rd 4, flush 0, corrupt 0, gen 0
May 15 10:55:14 vader kernel: BTRFS error (device nvme0n1p3): bdev /dev/nvme1n1p1 errs: wr 2, rd 4, flush 0, corrupt 0, gen 0
May 15 10:55:14 vader kernel: BTRFS error (device nvme0n1p3): bdev /dev/nvme1n1p1 errs: wr 3, rd 4, flush 0, corrupt 0, gen 0
May 15 10:55:14 vader kernel: BTRFS error (device nvme0n1p3): bdev /dev/nvme1n1p1 errs: wr 4, rd 4, flush 0, corrupt 0, gen 0
May 15 10:55:14 vader kernel: BTRFS error (device nvme0n1p3): bdev /dev/nvme1n1p1 errs: wr 6, rd 4, flush 0, corrupt 0, gen 0
May 15 10:55:14 vader kernel: BTRFS error (device nvme0n1p3): bdev /dev/nvme1n1p1 errs: wr 5, rd 4, flush 0, corrupt 0, gen 0
May 15 10:55:14 vader systemd[1]: Started systemd-rfkill.service - Load/Save RF Kill Switch Status.
May 15 10:55:14 vader kernel: BTRFS warning (device nvme0n1p3): lost super block write due to IO error on /dev/nvme1n1p1 (-5)
May 15 10:55:14 vader dbus-daemon[963]: [system] Rejected send message, 0 matched rules; type="error", sender=":1.3274" (uid=1000 pid=397855 comm="/usr/bi>
May 15 10:55:14 vader dbus-daemon[963]: [system] Rejected send message, 0 matched rules; type="error", sender=":1.3274" (uid=1000 pid=397855 comm="/usr/bi>
May 15 10:55:14 vader dbus-daemon[963]: [system] Rejected send message, 0 matched rules; type="error", sender=":1.3274" (uid=1000 pid=397855 comm="/usr/bi>
May 15 10:55:14 vader dbus-daemon[963]: [system] Rejected send message, 0 matched rules; type="error", sender=":1.3274" (uid=1000 pid=397855 comm="/usr/bi>
May 15 10:55:14 vader dbus-daemon[963]: [system] Rejected send message, 0 matched rules; type="error", sender=":1.3274" (uid=1000 pid=397855 comm="/usr/bi>
May 15 10:55:14 vader dbus-daemon[963]: [system] Rejected send message, 0 matched rules; type="error", sender=":1.3274" (uid=1000 pid=397855 comm="/usr/bi>
May 15 10:55:14 vader dbus-daemon[963]: [system] Rejected send message, 0 matched rules; type="error", sender=":1.3274" (uid=1000 pid=397855 comm="/usr/bi>
May 15 10:55:14 vader dbus-daemon[963]: [system] Rejected send message, 0 matched rules; type="error", sender=":1.3274" (uid=1000 pid=397855 comm="/usr/bi>
May 15 10:55:14 vader systemd[1]: user.slice: Unit now thawed.
May 15 10:55:14 vader systemd[1]: user-1000.slice: Unit now thawed.
May 15 10:55:14 vader systemd[1]: user@1000.service: Unit now thawed.
May 15 10:55:14 vader systemd[1]: session-94.scope: Unit now thawed.
May 15 10:55:14 vader systemd-sleep[438122]: Successfully thawed unit 'user.slice'.
May 15 10:55:14 vader dbus-daemon[963]: [system] Rejected send message, 0 matched rules; type="error", sender=":1.3274" (uid=1000 pid=397855 comm="/usr/bi>
May 15 10:55:14 vader dbus-daemon[963]: [system] Rejected send message, 0 matched rules; type="error", sender=":1.3274" (uid=1000 pid=397855 comm="/usr/bi>
May 15 10:55:14 vader dbus-daemon[963]: [system] Rejected send message, 0 matched rules; type="error", sender=":1.3274" (uid=1000 pid=397855 comm="/usr/bi>
May 15 10:55:14 vader dbus-daemon[963]: [system] Rejected send message, 0 matched rules; type="error", sender=":1.3274" (uid=1000 pid=397855 comm="/usr/bi>
May 15 10:55:14 vader dbus-daemon[963]: [system] Rejected send message, 0 matched rules; type="error", sender=":1.3274" (uid=1000 pid=397855 comm="/usr/bi>
May 15 10:55:14 vader dbus-daemon[963]: [system] Rejected send message, 0 matched rules; type="error", sender=":1.3274" (uid=1000 pid=397855 comm="/usr/bi>
May 15 10:55:14 vader dbus-daemon[963]: [system] Rejected send message, 0 matched rules; type="error", sender=":1.3274" (uid=1000 pid=397855 comm="/usr/bi>
May 15 10:55:14 vader dbus-daemon[963]: [system] Rejected send message, 0 matched rules; type="error", sender=":1.3274" (uid=1000 pid=397855 comm="/usr/bi>
May 15 10:55:14 vader dbus-daemon[963]: [system] Rejected send message, 0 matched rules; type="error", sender=":1.3274" (uid=1000 pid=397855 comm="/usr/bi>
May 15 10:55:14 vader dbus-daemon[963]: [system] Rejected send message, 0 matched rules; type="error", sender=":1.3274" (uid=1000 pid=397855 comm="/usr/bi>
May 15 10:55:14 vader dbus-daemon[963]: [system] Rejected send message, 0 matched rules; type="error", sender=":1.3274" (uid=1000 pid=397855 comm="/usr/bi>
May 15 10:55:14 vader systemd[1]: systemd-suspend.service: Deactivated successfully.
May 15 10:55:14 vader systemd[1]: Finished systemd-suspend.service - System Suspend.
May 15 10:55:14 vader systemd[1]: Stopped target sleep.target - Sleep.
May 15 10:55:14 vader systemd[1]: Reached target suspend.target - Suspend.
May 15 10:55:14 vader systemd[1]: Starting grub-common.service - Record successful boot for GRUB...
May 15 10:55:14 vader systemd[1]: Stopped target suspend.target - Suspend.
May 15 10:55:14 vader systemd-logind[1292]: Operation 'suspend' finished.
May 15 10:55:14 vader NetworkManager[1172]: <info>  [1778842514.2639] manager: sleep: wake requested (sleeping: yes  enabled: yes)
May 15 10:55:14 vader ModemManager[1083]: <msg> [sleep-monitor-systemd] system is resuming
May 15 10:55:14 vader NetworkManager[1172]: <info>  [1778842514.2648] device (enp5s0): state change: unmanaged -> unavailable (reason 'managed', managed-t>
May 15 10:55:14 vader kernel: BTRFS error (device nvme0n1p3): error writing primary super block to device 2
May 15 10:55:14 vader kernel: Generic FE-GE Realtek PHY r8169-0-500:00: attached PHY driver (mii_bus:phy_addr=r8169-0-500:00, irq=MAC)
May 15 10:55:14 vader kernel: BTRFS warning (device nvme0n1p3): lost super block write due to IO error on /dev/nvme1n1p1 (-5)
May 15 10:55:14 vader kernel: BTRFS error (device nvme0n1p3): error writing primary super block to device 2
May 15 10:55:14 vader kernel: BTRFS warning (device nvme0n1p3): lost super block write due to IO error on /dev/nvme1n1p1 (-5)
May 15 10:55:14 vader kernel: BTRFS error (device nvme0n1p3): error writing primary super block to device 2
May 15 10:55:14 vader kernel: BTRFS warning (device nvme0n1p3): lost super block write due to IO error on /dev/nvme1n1p1 (-5)
May 15 10:55:14 vader kernel: BTRFS error (device nvme0n1p3): error writing primary super block to device 2
May 15 10:55:14 vader kernel: BTRFS warning (device nvme0n1p3): lost super block write due to IO error on /dev/nvme1n1p1 (-5)
May 15 10:55:14 vader kernel: BTRFS error (device nvme0n1p3): error writing primary super block to device 2
May 15 10:55:14 vader kernel: BTRFS warning (device nvme0n1p3): lost super block write due to IO error on /dev/nvme1n1p1 (-5)
May 15 10:55:14 vader kernel: BTRFS error (device nvme0n1p3): error writing primary super block to device 2
May 15 10:55:14 vader kernel: BTRFS warning (device nvme0n1p3): lost super block write due to IO error on /dev/nvme1n1p1 (-5)
May 15 10:55:14 vader kernel: BTRFS error (device nvme0n1p3): error writing primary super block to device 2

From there, I see a continuous stream of errors that lasts all the way until reboot earlier today. They are various combinations of the following lines:

May 15 11:13:03 vader kernel: BTRFS warning (device nvme0n1p3): lost super block write due to IO error on /dev/nvme1n1p1 (-5)
May 15 11:13:03 vader kernel: BTRFS warning (device nvme0n1p3): lost super block write due to IO error on /dev/nvme1n1p1 (-5)
May 15 11:13:03 vader kernel: BTRFS warning (device nvme0n1p3): lost super block write due to IO error on /dev/nvme1n1p1 (-5)
May 15 11:13:03 vader kernel: BTRFS error (device nvme0n1p3): error writing primary super block to device 2
May 15 11:13:17 vader kernel: btrfs_dev_stat_inc_and_print: 15 callbacks suppressed
May 15 11:13:17 vader kernel: BTRFS error (device nvme0n1p3): bdev /dev/nvme1n1p1 errs: wr 557066, rd 12930, flush 593, corrupt 0, gen 0
May 15 11:13:17 vader kernel: BTRFS error (device nvme0n1p3): bdev /dev/nvme1n1p1 errs: wr 557067, rd 12930, flush 593, corrupt 0, gen 0
May 15 11:13:17 vader kernel: BTRFS error (device nvme0n1p3): bdev /dev/nvme1n1p1 errs: wr 557068, rd 12930, flush 593, corrupt 0, gen 0

Thanks in advance for any help.

This is a X-Post…

I’m still very new to having a home NAS. I thought it would be good to get it off of Google so I can have more control and save some money…

So I bought a Zettlab D8 Ultra and it looks like at some point while playing with settings and restarting the system (shutdown through system, and power back on) my pool became unreadable.

It seems the ZettOs uses BTRFS, and it looks like an MDADM control for Raid 5. I’ve been using Gemini to try and recover the data but it seems I’m just going in circles and I’m just wondering if I need to give up. I asked Gemini to give me a summary of what has been done. I’d like to try to recover the files so here is what Gemini told me we did (this is a straight copy paste from Gemini output). If anyone has any suggestions on what to try I’m happy to give it a shot.

——-

BTRFS on Linux Software RAID5 recovery help - Parent transid verify failed & Corrupt Chunk Tree after stripping bcache

\*\*TL;DR:\*\*

Recovering a 21TB storage pool (4x 24TB HDDs in RAID5). Originally wrapped in bcache with BTRFS on top. Bcache stripped cleanly (dirty\_data was 0.0k). BTRFS superblock is perfectly aligned via loop offset, but filesytem won't mount/restore due to a corrupt chunk tree (\`cannot read chunk root\`) and \`parent transid verify failed\` on all backup roots. Standard tools are core-dumping due to array size. Looking for advanced recovery paths.

\*\*\*

\### 1. Hardware & Environment Stack

\* \*\*Hardware:\*\* Zettlab D8 Ultra (Intel x86) with 4x 24TB HDDs.

\* \*\*OS / Environment:\*\* Ubuntu Live USB.

\* \*\*Storage Layout:\*\* Physical drives form a healthy Linux Software RAID 5 array (\`/dev/md126\` / \`/dev/md127\`). A bcache caching layer wrapper (\`bcache0\`) was mapped on top, formatted with BTRFS.

\---

\### 2. What We Have Done So Far

\#### Phase A: Removing Bcache & Finding the BTRFS Offset

Because the block layer was confirmed healthy and \`dirty\_data\` was verified at \`0.0k\` (cache fully flushed to the RAID), we opted to strip the bcache header directly from the production disks to expose the raw BTRFS pool without a massive 21TB clone image.

1. \*\*Stopped bcache device node:\*\*

   \`\`\`bash

   echo 1 | sudo tee /sys/block/bcache0/bcache/stop

   \`\`\`

2. \*\*Wiped bcache superblock signature:\*\*

   \`\`\`bash

   sudo wipefs -o 0x1018 /dev/md126

   \`\`\`

3. \*\*Scanned for BTRFS magic string offset:\*\*

   \`\`\`bash

   sudo grep --only-matching --byte-offset --text "\_BHRfS\_M" /dev/md126

   \`\`\`

   \*Result:\* Found \`\_BHRfS\_M\` at byte \`73792\`. Since a BTRFS primary superblock always sits exactly 64 KiB (\`65536\` bytes) into its data partition, the math confirmed a precise structural offset of \*\*\`8192\` bytes (8 KiB)\*\* (\`73792 - 65536 = 8192\`).

4. \*\*Mapped the exact 8 KiB offset boundary via loop device:\*\*

   \`\`\`bash

   sudo losetup --find --show --offset 8192 --sector-size 512 /dev/md127

   \`\`\`

   \*Result:\* Mapped cleanly to \`/dev/loop17\`. Running \`sudo btrfs inspect-internal dump-super /dev/loop17\` successfully decodes the filesystem parameters with zero alignment or "bad magic" errors. The block layer mapping is 100% verified.

\---

\### 3. The Core Issue: Deep Metadata Corruption

Once the loop device opened the BTRFS superblock cleanly, we attempted multiple methods to mount or pull files. Every single approach has hit a brick wall due to multi-layered metadata corruption:

\#### 1. Transaction ID Verification Failures (\`parent transid verify failed\`)

The kernel log (\`dmesg\`) reveals that the primary tree root and all four native fallback backup root slots (0, 1, 2, and 3) are corrupt. The transaction generations expected by the superblock (\`46632\` to \`46635\`) completely mismatch the actual generations found on those blocks (ranging wildly from \`47544\` to \`146281\`).

\#### 2. Broken Chunk Tree Map

We extracted the raw root addresses from the superblock layout:

\`\`\`bash

sudo btrfs inspect-internal dump-super -f /dev/loop17 | grep -A 25 -E "backup\_roots"

\`\`\`

\*Result:\* All four backup slots reference the exact same chunk root address (\`26017792\`) at generation \`46596\`. This chunk root is unreadable. Without a functioning chunk tree, BTRFS cannot translate logical virtual addresses into real, physical device segments.

\#### 3. Command Failures Encountered:

\* \`sudo mount -t btrfs -o ro,usebackuproot /dev/loop17 /mnt/recovery\` -> Fails with \`open\_ctree failed: -5\`.

\* \`sudo btrfs restore /dev/loop17 /tmp\` -> Aborts immediately with \`cannot read chunk root\`.

\* \`sudo mount -t btrfs -o ro,rescue=usebackuproot,rescue=ignorebadroots,rescue=nolog /dev/loop17 /mnt/recovery\` -> Kernel rejects the mount due to the corrupt chunk tree maps.

\* \`sudo btrfs-find-root /dev/loop17\` -> Triggers a \`Bus error (core dumped)\` because it runs out of memory or hits a kernel boundary trying to scan the massive 21TB metadata space sequentially on a Live USB environment.

\---

\### Current Status

\* The physical disks and RAID5 parity are completely healthy and active.

\* The structural block offset (\`8192\` bytes) is completely correct and verified.

\* Standard kernel mount paths and user-space recovery utilities (\`btrfs restore\`) are deadlocked by the broken chunk tree.

All my data on all 4 hardrives was deleted. This is my take on what I think happened.

Setup:

Debian 13

@ subvol mounted to /

@home subvol mounted to /home

Installed snapper and created a snap called core and it was snapshot number 1.

I edited /etc/fstab to mount hard drives to /media/folderName

I messed around with some files and ran snapper -c root undochanges 1..0 and rebooted.

Did this delete my files because /media was not a subvol?

So I have a RAID-5 BTRFS filesystem using 4@6TB drives. I lost a disk, replaced it, and during the reboot, had a power outage longer than my UPS could handle. So my filesystem, when it came back, was extremely corrupted. I was able to recover the files I needed (home movies, etc) but there were a ton of rips of media - around 2500 files - that didn't make it. I knew the risks going in, and the plan has always been if this filesystem barfs I would just re-rip or download the stuff I care about. My question for the group is, are there any options that I have not considered to recover this data?

Scrubs come back with a lot of uncorrectable errors.

UID:             <redacted>
Scrub started:    Fri May  8 14:30:59 2026
Status:           running
Duration:         20:08:08
Time left:        143:02:07
ETA:              Fri May 15 09:41:16 2026
Total to scrub:   12.65TiB
Bytes scrubbed:   1.56TiB  (12.34%)
Rate:             22.58MiB/s (some device limits set)
Error summary:    csum=79663859
  Corrected:      0
  Uncorrectable:  79663859^C

Now, while I am not heartbroken thanks to my plan for this data going in, there will be a lot of effort involved in re-ripping all my media. Are there any options available to me to try to recover additional files?

Hey everyone,

I’m on CachyOS (EliteBook, NVMe) and I’ve hit a critical wall with Btrfs. My metadata (DUP) reached 94.22% saturation due to a massive Monero blockchain sync, and now the filesystem is stuck in a Read-Only loop.

The Current Situation:

btrfs fi usage shows: Metadata (DUP) is 11.31GiB used out of 12.00GiB.

The Error: Whenever I try to delete files or run a balance, I get ERROR: quota rescan failed: Transport endpoint is not connected or the system flips back to ro.

The Problem: Even on a Live USB, I can't seem to stay in rw long enough to rm the large files. The kernel seems to fence off the drive the moment I try to commit a transaction.

What I've tried:

btrfs rescue zero-log (successfully clears, but the metadata wall remains).

mount -o remount,rw,nospace\_cache,clear\_cache.

btrfs balance start -m (fails because there’s no room to create a new metadata chunk).

I also use Hyprland (CachyOS ml4w)

Yestrerday I noticed that one of my drives fails to mount.

Trying to mount the drive the drive on my CachyOS machine fails with "can't read superblock", however btrfs rescue super-recover returns "All supers are valid, no need to recover".

However, running btrfs check fails with the following message:
fish: Job 1, 'sudo btrfs check --readonly /de…' terminated by signal SIGSEGV (Address boundary error)

The same thing happens on a Debian Live-ISO (gparted-live-1.8.1-3) and when compiling btrfs-progs from source.

SMART says the drive is ok and I was actively using it before rebooting.

With GDB I got the following backtrace:

#0  calc_extent_flag (extent_cache=extent_cache@entry=0x7fffffffdfd0, buf=buf@entry=0x5555598f1890, ri=ri@entry=0x0, flags=0x7fffffffd9d8) at check/main.c:6346
#1  0x000055555560066d in run_next_block (root=root@entry=0x555555698860, bits=bits@entry=0x555556180040, last=last@entry=0x7fffffffdd78, pending=pending@entry=0x7fffffffdfe0, seen=seen@entry=0x7fffffffdfd8,
    reada=reada@entry=0x7fffffffdfe8, nodes=0x7fffffffdff0, extent_cache=0x7fffffffdfd0, chunk_cache=0x7fffffffdfc8, dev_cache=0x7fffffffdfc0, block_group_cache=0x7fffffffe100, dev_extent_cache=0x7fffffffe0a0, ri=0x0, bits_nr=1024)
    at check/main.c:6534
#2  0x0000555555602b0a in deal_root_from_list (list=list@entry=0x7fffffffe010, root=root@entry=0x555555698860, bits=bits@entry=0x555556180040, pending=pending@entry=0x7fffffffdfe0, seen=seen@entry=0x7fffffffdfd8,
    reada=reada@entry=0x7fffffffdfe8, nodes=0x7fffffffdff0, extent_cache=0x7fffffffdfd0, chunk_cache=0x7fffffffdfc8, dev_cache=0x7fffffffdfc0, block_group_cache=0x7fffffffe100, dev_extent_cache=0x7fffffffe0a0, bits_nr=1024)
    at check/main.c:8975
#3  0x0000555555603b41 in check_chunks_and_extents () at check/main.c:9290
#4  0x0000555555608e88 in do_check_chunks_and_extents () at check/main.c:9386
#5  cmd_check (cmd=<optimized out>, argc=<optimized out>, argv=<optimized out>) at check/main.c:11022
#6  0x000055555556ffd6 in cmd_execute (cmd=0x55555568c3c0 <cmd_struct_check>, argc=<optimized out>, argv=<optimized out>) at cmds/commands.h:126
#7  main (argc=<optimized out>, argv=<optimized out>) at btrfs.c:474

Is this something I should report as a bug?
I'm assuming, --repair wouldn't work either because of this bug, but I would like to try and recover my data. (I have a backup, so it's more of a curiosity thing)