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_btrfs@merlins.org>]

Thanks both for the answers.
> 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.

1) there was no system crash or power off that I can remember, at least
not recently.
2) I do have all the logs from the start, here they are: https://pastebin.com/7HmQwy3n
3) AI may have been wrong about linking me enabling trim to the crash
but they sure happened a few minutes apart. Could have been coincidence.
4) write hole: I do have md5 "Intent Bitmap : Internal" which indeed
prioritizes rebuild over fixing the write hole (mdadm can't do both,
sadly). I'm honestly sad that mdadm does not allow PPL (closing write
hole and intent bitmap for reasonable rebuild times)
5) the mdadm layer does not help, I would love to use built in btrfs
raid5 but last info I read still says it also has write hole or other
issues and can't really ever be production ready
5) RST is supposed to fix this but https://btrfs.readthedocs.io/en/latest/Status.html
says it's not ready, and why I asked about status recently, no answer
yet: https://yhbt.net/lore/linux-btrfs/adbgT-3VINfJNctk@merlins.org/#r

So raid5 and btrfs are still problematic :-/

On Sat, Apr 11, 2026 at 02:17:24PM +0930, Qu Wenruo wrote:
> Please try skip_balance to see if the fs can be mounted, then cancel the
> relocation.
 
I tried many mounts with skip_balance, they all still crashed.
You can find them all in https://pastebin.com/7HmQwy3n

> Then re-run btrfs check so we do not have balance complicating the
> situation.
 
My first one crashed due to OOM, I added 64GB swap and am trying again.

> > btrfstune --convert-from-block-group-tree /dev/mapper/crypt_bcache0
> 
> Please do not do whatever writes to the fs until you know why you should do
> that.
> And in this case, this will only make things worse.

Sequence of mount commands:
mount -t btrfs -o ro,nologreplay,skip_balance,clear_cache /dev/mapper/crypt_bcache0 /mnt/btrfs_bigbackup
umount /mnt/btrfs_bigbackup
=> worked, but ro

mount -t btrfs -o ro,nologreplay,skip_balance,clear_cache /dev/mapper/crypt_bcache0 /mnt/btrfs_bigbackup/
mount -o remount,rw,skip_balance /mnt/btrfs_bigbackup/
umount /mnt/btrfs_bigbackup/
=> Could not remount with skip_balance

all of these failed and caused the mounts in https://pastebin.com/7HmQwy3n
mount -t btrfs -o nologreplay,skip_balance,clear_cache /dev/mapper/crypt_bcache0 /mnt/btrfs_bigbackup/
mount -t btrfs -o skip_balance,clear_cache /dev/mapper/crypt_bcache0 /mnt/btrfs_bigbackup/
mount -t btrfs -o skip_balance,usebackuproot /dev/mapper/crypt_bcache0 /mnt/btrfs_bigbackup/
mount -t btrfs -o skip_balance /dev/mapper/crypt_bcache0 /mnt/btrfs_bigbackup/
mount -t btrfs -o rw,skip_balance,space_cache=v2,clear_cache /dev/mapper/crypt_bcache0 /mnt/btrfs_bigbackup

Once I dropped the cache (clear_cache), I was forced to downgrade
with --convert-from-block-group-tree 

> Now I do not even know if this is the original problem or something
> introduced by your writes.
 
Hopefully https://pastebin.com/7HmQwy3n shows the original issue
 
> Next time, please do not do whatever crazy/stupid things unless *YOU* know
> the reason.

I'm in the middle of a maintenance, I don't have a support contract with
you the few people who know who to read this, and to be honest I have
found pretty much no good debug info or guide on the net.
Even looking for the status of RST and how usable, it is, or not, I
found nothing on the official pages, and when I wrote on this list to
ask, I got 0 reply.

So I'm not saying it's great or smart to use an LLM, but if there is no
easily findable (or any) information on how to debug all those things
without reading/knowing the kernel code, what is the recommended path
for an end user?

Thanks,
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