Re: BTRFS discard crash: failed to run delayed ref for logical 15506102321152 num_bytes 16384 type 182 action 2 ref_mod 1: -2 6.11.2)

[Roman Mamedov <rm@romanrm.net>]

On Sun, 12 Apr 2026 13:21:46 -0700
Marc MERLIN <marc@merlins.org> wrote:

> One last ditch effort from Gemini:

I think you'd better not put LLM usage in the forefront of your messages :)
Let alone copy and paste entire unedited paragraphs from it.
It acts as a red herring to many people, and those who would otherwise read
your posts and try to answer, will just glance over entirely.

> moremagic:~# btrfs rescue zero-log /dev/mapper/crypt_bcache0
> Clearing log on /dev/mapper/crypt_bcache0, previous log_root 0, level 0
> moremagic:~# mount -o rw,clear_cache,skip_balance /dev/mapper/crypt_bcache0 /mnt/btrfs_bigbackup
> mount: /mnt/btrfs_bigbackup: fsconfig() failed: No such file or directory.
>        dmesg(1) may have more information after failed mount system call.
> moremagic:~# mount -wno remount,skip_balance /mnt/btrfs_bigbackup/
> ^^^ works, filesystem is still there:
> 
> Read/write still failing :-/

Nothing wrong with just "this is what I tried and it didn't help", it's not as
important that LLM was the source of the ideas to try.

> Gemini says the following

Everyone has access to Gemini, and if Btrfs developers would be interested in
what it has to say about their filesystem, they could go and ask it directly :)

Secondly, I feel when others DO answer and something doesn't look right, you
may start your objection with "But Gemini said..."
And that's a whole another story, arguing with a person wielding an LLM and
trusting it more than a person in front of them. Many have been there by now
I'm sure. :)

> details, it would be nice to have a way to btrfs --repair or force
> cleanup/revert/delete on read-write mount to recover to a working state.
> Coping 22TB off from r/o FS is pointless, it's an offsite backup, never mind
> that I have nowhere to copy that too anyway, I really would like to
> get it back to read/write if there isn't massive corruption, and there
> does not seem to be.
> 
> Btrfs operates on a strict "clean up your mess first" policy.
> Read-Only: The kernel simply reads the B-trees as they currently exist
> on the disk. It completely ignores the Btrfs "to-do" list (the delayed
> refs and the aborted relocation tree).
> Read-Write: The kernel refuses to let you write new data until it
> finishes the aborted relocation from when the system crashed days
> ago. It tries to execute that "to-do" list, hits the corrupted Extent
> Tree/Squota bug (ENOENT), and instantly panics and aborts the mount to
> prevent further corruption.
> 
> Because there is no skip_relocation mount option in the Linux kernel,
> you cannot force this filesystem to mount Read-Write without clearing
> that broken tree. And because standard tools cannot clear a broken
> relocation tree offline, the RW mount is effectively bricked.

-- 
With respect,
Roman