public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Mikkel Jeppesen <mikkel@mikkel.cc>
To: mikkel+btrfs@mikkel.cc, Qu Wenruo <wqu@suse.com>,
	lists@colorremedies.com, Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: kernel 6.17 and 6.18, WARNING: CPU: 5 PID: 7181 at fs/btrfs/inode.c:4297 __btrfs_unlink_inode, forced readonly
Date: Wed, 17 Dec 2025 19:42:54 +0100	[thread overview]
Message-ID: <2234039.9o76ZdvQCi@localhost-live> (raw)
In-Reply-To: <5d5e344e-96be-4436-9a58-d60ba14fdb4f@gmx.com>

On Tuesday, December 16, 2025 6:42:28 AM Central European Standard Time Qu 
Wenruo wrote:
> 在 2025/12/16 11:44, mikkel@mikkel.cc 写道:
> > On Tuesday, December 16, 2025 12:05:54 AM Central European Standard Time
> > Qu
> 
> > Wenruo wrote:
> [...]
> It's indeed a bitflip, and in a pretty bad location, making the initial
> repair doing a bad job.
> 
> 
> Firstly there is a DIR_ITEM that is the offending one in subvolume 256:
> 
> 	item 148 key (1924 DIR_ITEM 2435677723) itemoff 5853 itemsize 70
> 		location key (730455 INODE_ITEM 0) type FILE
> 		transid 7280 data_len 0 name_len 40
> 		name: AC1E6A9C763DC6BC77494D6E8DE724C240D36C9E
> 
> However there is no DIR_INDEX one for it.
> I believe this is caused by the initial repair.
> 
> Then for the offending inode, it exists!
> 
> 	item 10 key (730455 INODE_ITEM 0) itemoff 15456 itemsize 160
> 		generation 7280 transid 9794 size 13829 nbytes 16384
> 		block group 0 mode 100600 links 1 uid 1000 gid 1000 rdev 
0
> 		sequence 11 flags 0x0(none)
> 		atime 1765397443.29231914 (2025-12-11 06:40:43)
> 		ctime 1764798591.882909548 (2025-12-04 08:19:51)
> 		mtime 1764798591.882909548 (2025-12-04 08:19:51)
> 		otime 1764712848.413821734 (2025-12-03 08:30:48)
> 	item 11 key (730455 UNKNOWN.8 1924) itemoff 15406 itemsize 50
> 
> Note the item 11, which has an unknown type 8. But normally this should
> be INODE_REF, and the size matches the namelen + 10.
> 
> bin(8)  = 0b1000
> bin(12) = 0b1100
> 
> Diff is exact one bit, so it's again a bitflip.
> 
> This means there are several problems in the original mode at
> least:(lowmem mode should be able to do better, but the metadata is too
> large thus lowmem mode is too slow to be practical)
> 
> - Unknown key type detection
>    Every time we hit an unknown key type, we should give some warning to
>    help debugging at least.
> 
> - Inode nlink checks is not properly checking INODE_REF
> 
> Since this has a back INODE_REF item, I have to manually fix it, you can
> fetch the following branch:
> 
>    https://github.com/adam900710/btrfs-progs/tree/dirty_fix
> 
> Then compile it, you will get "btrfs-corrupt-block" at the project top
> directory.
> 
> Then:
>    ./btrfs-corrupt-block -X <device>
> 
> Which will fix the inode ref.
> 
> Now btrfs check should report a different error:
> 
>   ...
>   [5/8] checking fs roots
>   	unresolved ref dir 1924 index 134016 namelen 40 name
> AC1E6A9C763DC6BC77494D6E8DE724C240D36C9E filetype 1 errors 2, no dir index
>   ERROR: errors found in fs roots
>   ...
> 
> This is the indicator that the repair is done correctly (errors 2).
> 
> Then "btrfs check --repair" should be able to repair it:
> 
>   enabling repair mode
>   Opening filesystem to check...
>   Checking filesystem on /home/adam/test.img
>   UUID: afdbb979-0b91-499b-976c-0244ba2ed38f
>   [1/8] checking log skipped (none written)
>   [2/8] checking root items
>   Fixed 0 roots.
>   [3/8] checking extents
>   super bytes used 166880690176 mismatches actual used 166880575488
>   No device size related problem found
>   [4/8] checking free space tree
>   [5/8] checking fs roots
>   repairing missing dir index item for inode 730455
>   reset isize for dir 1924 root 256
>   [6/8] checking only csums items (without verifying data)
>   [7/8] checking root refs
>   [8/8] checking quota groups skipped (not enabled on this FS)
>   found 333761265664 bytes used, no error found
>   total csum bytes: 322896656
>   total tree bytes: 2385526784
>   total fs tree bytes: 1857060864
>   total extent tree bytes: 164102144
>   btree space waste bytes: 411870645
>   file data blocks allocated: 1029749325824
>    referenced 404780113920
> 
> Thanks,
> Qu

This did indeed do the trick! :)

sudo ./btrfs-corrupt-block -X /dev/sda3
Repaired the bad inode ref key

sudo btrfs check /dev/sda3
Opening filesystem to check...
Checking filesystem on /dev/sda3
UUID: afdbb979-0b91-499b-976c-0244ba2ed38f
[1/8] checking log skipped (none written)
[2/8] checking root items
[3/8] checking extents
[4/8] checking free space tree
[5/8] checking fs roots
        unresolved ref dir 1924 index 134016 namelen 40 name 
AC1E6A9C763DC6BC77494D6E8DE724C240D36C9E filetype 1 errors 2, no dir index
ERROR: errors found in fs roots
found 167377907712 bytes used, error(s) found
total csum bytes: 161874964
total tree bytes: 1243725824
total fs tree bytes: 976257024
total extent tree bytes: 84213760
btree space waste bytes: 214400581
file data blocks allocated: 511281180672
 referenced 203289292800

sudo btrfs check --repair /dev/sda3 
enabling repair mode
WARNING:

        Do not use --repair unless you are advised to do so by a developer
        or an experienced user, and then only after having accepted that no
        fsck can successfully repair all types of filesystem corruption. E.g.
        some software or hardware bugs can fatally damage a volume.
        The operation will start in 10 seconds.
        Use Ctrl-C to stop it.
10 9 8 7 6 5 4 3 2 1
Starting repair.
Opening filesystem to check...
Checking filesystem on /dev/sda3
UUID: afdbb979-0b91-499b-976c-0244ba2ed38f
[1/8] checking log skipped (none written)
[2/8] checking root items
Fixed 0 roots.
[3/8] checking extents
No device size related problem found
[4/8] checking free space tree
[5/8] checking fs roots
repairing missing dir index item for inode 730455
reset isize for dir 1924 root 256
[6/8] checking only csums items (without verifying data)
[7/8] checking root refs
[8/8] checking quota groups skipped (not enabled on this FS)
found 167377907712 bytes used, no error found
total csum bytes: 161874964
total tree bytes: 1243725824
total fs tree bytes: 976257024
total extent tree bytes: 84213760
btree space waste bytes: 214400581
file data blocks allocated: 511281180672
 referenced 203289292800

sudo btrfs check /dev/sda3 
Opening filesystem to check...
Checking filesystem on /dev/sda3
UUID: afdbb979-0b91-499b-976c-0244ba2ed38f
[1/8] checking log skipped (none written)
[2/8] checking root items
[3/8] checking extents
[4/8] checking free space tree
[5/8] checking fs roots
[6/8] checking only csums items (without verifying data)
[7/8] checking root refs
[8/8] checking quota groups skipped (not enabled on this FS)
found 167377907712 bytes used, no error found
total csum bytes: 161874964
total tree bytes: 1243725824
total fs tree bytes: 976257024
total extent tree bytes: 84213760
btree space waste bytes: 214400236
file data blocks allocated: 511281180672
 referenced 203289292800








      reply	other threads:[~2025-12-17 18:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-11  1:28 kernel 6.17 and 6.18, WARNING: CPU: 5 PID: 7181 at fs/btrfs/inode.c:4297 __btrfs_unlink_inode, forced readonly Chris Murphy
2025-12-11  1:55 ` Qu Wenruo
2025-12-11 18:01   ` Chris Murphy
2025-12-11 18:52     ` Chris Murphy
2025-12-11 21:07       ` Chris Murphy
2025-12-15  9:02     ` Qu Wenruo
2025-12-15 14:47       ` Chris Murphy
2025-12-15 22:03         ` Mikkel Jeppesen
     [not found]         ` <acefecca-9fbb-4268-a26a-b889756019e7@mikkel.cc>
2025-12-15 23:05           ` Qu Wenruo
2025-12-16  1:14             ` mikkel
2025-12-16  5:42               ` Qu Wenruo
2025-12-17 18:42                 ` Mikkel Jeppesen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2234039.9o76ZdvQCi@localhost-live \
    --to=mikkel@mikkel.cc \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.com \
    --cc=mikkel+btrfs@mikkel.cc \
    --cc=quwenruo.btrfs@gmx.com \
    --cc=wqu@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox