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)

[Marc MERLIN <marc@merlins.org>]

On Mon, Apr 13, 2026 at 07:14:19AM +0500, Roman Mamedov wrote:
> I think you'd better not put LLM usage in the forefront of your messages :)

I'm just being honest about how I got the commands, due to lack of
better online source I was able to find.

> > 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 :)
 
I don't quite agree. If google search (before) and gemini (now) are
giving incorrect and potentially harmful answers, it's actually
important to know. 
I'm a developer myself (for much simpler userspace code), and if I don't
have sufficient docs for my software and users end up finding and doing
the wrong things from google searches or LLM suggestions, I need and
want to know.
 
> 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. :)
 
I absolutely do not trust an LLM over anyone here or any actual
published doc I can find.
I've been stuck for 3 days with a broken filesystem I need to fix,
cannot find any docs that help (but there may not be any), am providing
as many ample logs and commands on what I'm doing and the kernel errors
I'm getting, as well as the workflow that is getting me from A to B to
C, and why I'm going that route, even I'm entirely wrong in doing so.

I do not expect anyone here to answer every few hours or daily or during
the weekend, or at all sicne this list is technically not a support
list, but then again I'm not sure there is one (I asked, got no answer
on that topic), so I can't wait days or weeks for an answer that may
never come.
So given that, LLM is worst option I have, but it's also the only one left.
Some steps like btrfs repair which I had to try 3 times at up to half a
day of runtime each time, are also good that I already took them and 
finally got it to finish (and sadly fix nothing)

Still, even if my FS is hosed and no one can or has time to help, I'm
still spending the time to share what I found and hit, in case it can
help fix future kernels or versions of check --repair.

Since it's not safe for me to stay very long with my main backup mostly
dead/unusable, I'll wait another day or so in case any one here would
like to me to give more info/try things before I wipe, and if not, I'll
sadly have to do that and suck up the likely multi week data resync

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
 
Home page: http://marc.merlins.org/                       | PGP 7F55D5F27AAF9D08