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 Sat, Apr 11, 2026 at 06:57:33PM -0700, Marc MERLIN wrote:
> But this is strange lowmem is giving a totally different result, it may
> just be entirely trashing my FS as I write this, but if it doesn't
> succeed, I need to wipe it and start over anyway
> moremagic:~# btrfs check --mode lowmem /dev/mapper/crypt_bcache0
> Opening filesystem to check...
> Checking filesystem on /dev/mapper/crypt_bcache0
> UUID: a97dec85-a0d5-42ab-a0ef-e9b7479fbe43
> [1/8] checking log skipped (none written)
> [2/8] checking root items
> [3/8] checking extents
> ERROR: extent[16842752 168 4096] has unknown ref type: 172
> ERROR: extent[16855040 168 4096] has unknown ref type: 172
> ERROR: extent[1121296384 168 8192] has unknown ref type: 172
> 
> Gemnini said that's the simple quotas not supported in lowmem
> 
> moremagic:~# btrfstune --remove-simple-quota /dev/mapper/crypt_bcache0
> bad eb member end: ptr 0x4000 start 15495212859392 member offset 16384 size 1
> bad eb member end: ptr 0x4000 start 16568940527616 member offset 16384 size 1
> bad eb member end: ptr 0x4000 start 16133001379840 member offset 16384 size 1

I forgot to mention:
moremagic:~# btrfs --version
btrfs-progs v6.17.1
-EXPERIMENTAL -INJECT -STATIC +LZO +ZSTD +UDEV +FSVERITY +ZONED CRYPTO=builtin

And gemini could be completely wrong, but since I have no other source of help
while typing those commands, and I need that filesystem back up, or
ron the sameestoring from backup, this is what it says now

The error message bad eb member end: ptr 0x4000 start ... member offset
16384 size 1 is a smoking gun for an off-by-one bug in the tool's
bounds-checker:
0x4000 / 16384: This is exactly the default nodesize (16KB) for Btrfs.

Offset 16384, Size 1: The code is trying to read/write a 1-byte member
that starts at the very last byte of the buffer and ends at 16385.

The Conflict: Because the extent buffer is only 16384 bytes (0 to
16383), the strict validation in the btrfs-progs library (likely
check_eb_range in kernel-lib/extent_io.c) throws a warning and blocks
the operation.

Why this happened with Simple Quotas
The BTRFS_EXTENT_OWNER_REF_KEY (Type 172) that caused your lowmem check
to fail is relatively new (introduced in Kernel 6.7). The code for
--remove-simple-quota in btrfstune (v6.13+) has to iterate the extent
tree and delete these items.

(Speculation) There appears to be a bug in how the iterator handles the
"next item" pointer when a BTRFS_EXTENT_OWNER_REF_KEY is the last item
in a leaf, or when the leaf is being rebalanced after a deletion.

Suggestions/ideas welcome, including my previous question of is there
even really a way to do software raid5 on linux with btrfs without
getting those seemingly unfixable and unrepairable btrfs corruption
issues? (I say this because of that having been my experience over 11 years
of trying to do this and getting too many of these corruption problems,
almost all of which were unrepairable and required a very slow restore
process for terabytes of data)

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