Re: Space cache rebuild failed and reports fs corrupted

On Tue, Aug 11, 2026, at 12:00 AM, Alex Writing wrote:
> Hi, I just updated from Proxmox 8 to Proxmox 9, which updates from
> Debian 12 to Debian 13. The new kernel is a Proxmox-specific build of
> 7.0.14. btrfs-progs version is the latest version Proxmox provides,
> 6.14.
>
> After the update, my btrfs RAID1 HDD array failed to mount
> automatically at boot because it was timing out; it now takes 90-120
> seconds to mount the array for some reason. I turned on debugging and
> there are lots of lines like this during the delay:
>
> [Mon Aug 10 17:47:28 2026] BTRFS debug (device sdb1):
> btrfs_submit_dev_bio: rw 0 0x1000, sector=1924895456, dev=8388625
> (/dev/sdb1 id 2), size=16384
> [Mon Aug 10 17:47:28 2026] BTRFS debug (device sdb1):
> btrfs_submit_dev_bio: rw 0 0x1000, sector=5154454848, dev=8388625
> (/dev/sdb1 id 2), size=16384
>
> I read something online that suggested clearing the space cache. I
> tried that, which ran for about 15 minutes but then failed:

I am not a developer but they might want to know working kernel version, the failing kernel version, and the btrfs-progs version.

And then the exact command used to clear space cache. And mount options.



> btrfs check reports "errors found in extent allocation tree or chunk
> allocation" in the checking extents phase (mostly root 10 but a few in
> root 1 and root 4), and in the "checking free space tree" phase
> reports "could not load free space tree: No such file or directory"
> which makes sense since the space tree rebuild failed. It doesn't
> report any issues in any other phase.

Free space tree is the inverse of the extent tree. If free space tree is corrupt or needs to be replaced, then the extent tree needs to be consistent. If it has inconsistency it's a big problem for future writability of the file system because writing Btrfs is complex.

Whereas reads make no changes, and depend primarily on file tree.


>
> Here's the full btrfs check output: https://pastebin.com/XZFHLLvd

That looks bad.

Anyway, I suggest using the file system only in read-only mode and not attempt repair. It's not merely that they can make things worse but it quickly changes the file system state and makes it difficult for a developer to offer an opinion or possible fix.



> The logs show that one of the drives dropped out briefly during the
> btrfs check, so I'm guessing there may be a flaky cable or SATA port
> that might be the root cause of the issue. I'll also probably run a
> memtest before doing much more to it.

Definitely do a memtest as a first step, or memtester. And then do a scrub. Scrub can fix many more issues when data and metadata are raid1.



-- 
Chris Murphy