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 Fri, 10 Apr 2026 20:35:33 -0700
Marc MERLIN <marc@merlins.org> wrote:

> I had btfrs filesystem on top of raid5 with 5 spinning drives.
> I mistakenly enabled discard by mistake which caused a crash when the discard thread tried
> to run (no discard on those drives)
> Kernel 6.12
> 
> I worked on recovery using gemini 3.0 pro, mounting read only is fine, but I need read write
> or will waste days (probably weeks) recreating this entire 20TB+ backup over the internet
> 
> I'm not qualified to say if everything Gemini said was correct, but I think summary is:
> 1) discard can apparently kill a filesystem when it's hard drives below (it did for me)

Although some SMR HDDs might support TRIM, if you are certain none of yours
do, then issuing the TRIM command does not alter on-disk data in any way, and
after a device returns ENOTSUPP once, the block layer usually knows to stop
trying, it will return "not supported" to the upper layer right away, not
contacting the drive about that anymore.

As such it is unlikely that discard itself caused the issue in your case.
There is also no discard in the presented traces, and it is unfortunate you
didn't capture the initial "crash". So it might be just a coincidence, or it
might be not. And like Mr. Qu, I am also skeptical of the AI fantasies in this
case.

Be aware of the write hole issue when running Btrfs on top of a multi-device
mdraid. In case of a system crash, some devices might have stripes written and
synced to disk, and others not. This is can easily lead Btrfs into the
infamous "parent transid verify failed" state, from which there's no good way
out.

-- 
With respect,
Roman