Re: Read time tree block corruption detected

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

On 2021/7/18 下午6:34, pepperpoint@mb.ardentcoding.com wrote:
> Hi Qu,
>
> I boot an ISO with Linux 5.1.15, mount the filesystem, wait for a while and restart.
>
> This command did not output anything when I boot the system and run it:
> btrfs ins dump-tree -t extent /dev/dm-0 | grep 174113599488 -A 3
>
> Checking the logs, I do not see the error anymore from the time I boot the system. I also ran btrfs scrub just in case and detected no errors.
>
> I think the filesystem is now fixed?

Yep, as expected.

If you want to be extra extra sure, you can try another command (no need
to unmount the fs):

# btrfs ins dump-tree -t root /dev/dm-0 | grep "(363 ROOT"

It should has no output.

I'll later submit a patch to enhance btrfs-progs to detect such problem.

Thanks,
Qu
>
> Regards,
> Lester
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>
> On Sunday, July 18th, 2021 at 5:32 PM, Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>
>> On 2021/7/18 下午4:46, pepperpoint@mb.ardentcoding.com wrote:
>>
>>> Hi Qu,
>>>
>>> When I find which directory some of the filenames are located, they are under /var/lib.
>>>
>>> I had subvolume for /var which was created probably around 2018.
>>
>> Then it's possible by somehow we allowed that hardlink to directory.
>>
>> Not sure if it's a bug in VFS layer or in btrfs itself.
>>
>> But around 2019 (aka, v5.2 kernel), that check for refs of directory is
>>
>> introduced and at the same time, write-time tree checker is introduced.
>>
>> This means if the bug happens after v5.2 kernel, it will be rejected
>>
>> before submitting to disk.
>>
>> So the problem definitely happens before the install of v5.2 kernel.
>>
>>> I don't remember how I created this but I probably use rsync to copy the files from existing /var
>>>
>>> or created a snapshot of root and delete other files that is not under /var.
>>
>> But that's still pretty weird.
>>
>>> Around June, I tried to move the filesystem to another partition through btrfs device add and btrfs device remove
>>>
>>> but failed due to that error and was advised to use btrfs replace instead.
>>>
>>> Then at the beginning of this month, I reorganized it merging most of the /var content back to root
>>>
>>> and created subvolume for /var/lib/mysql and /var/lib/mongodb. I encountered an error when
>>>
>>> I copy some of the files through cp --reflink but I failed for /var/lib/mysql so I created a snapshot
>>>
>>> from /var and remove the extra files.
>>>
>>> This is also the time I saw the errors in the log. Before that, the errors was not in the log.
>>
>> At least, we should prevent such problem from reaching disk.
>>
>> If you reverted to older LTS kernel, using Arch Linux Archive, it would
>>
>> be possible to continue deleting the subvolume and solve the problem.
>>
>> After the root 363 get fully deleted, you can verify that tree block get
>>
>> deleted by the following command:
>>
>> btrfs ins dump-tree -t extent <device> | grep 174113599488 -A 3
>> ===============================================================
>>
>> Which should show no output.
>>
>> Thanks,
>>
>> Qu
>>
>>> Regards,
>>>
>>> Lester
>>>
>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>>
>>> On Sunday, July 18th, 2021 at 3:27 PM, Qu Wenruo quwenruo.btrfs@gmx.com wrote:
>>>
>>>> Hi,
>>>>
>>>> BTW, it's really important for us to know how the directory is hardlinked.
>>>>
>>>> Thus I salvaged the filenames found in the half-dropped root 363.
>>>>
>>>> Since it may contain confidential info, I send the filename list to you
>>>>
>>>> off-list.
>>>>
>>>> If you can remind what the root 363 is used for, and any possible
>>>>
>>>> operations which may be involved in that subvolume, it's better to reply
>>>>
>>>> it to the mail list so that we can get some clue on the root cause.
>>>>
>>>> Thanks,
>>>>
>>>> Qu
>>>>
>>>> On 2021/7/18 下午3:15, Qu Wenruo wrote:
>>>>
>>>>> On 2021/7/18 下午1:26, pepperpoint@mb.ardentcoding.com wrote:
>>>>>
>>>>>> Hi Qu,
>>>>>>
>>>>>> May I know if there are any leads on this? What should I do for now?
>>>>>
>>>>> Sorry for the late reply.
>>>>>
>>>>> With the image dump, it's much easier to find what's going wrong.
>>>>>
>>>>> -   About root 363
>>>>>
>>>>>      It's an orphan root, thus user can't access it directly.
>>>>>
>>>>>
>>>>> Furthermore, it's being dropped, thus "btrfs ins dump-tree -t 363"
>>>>>
>>>>> reports transid error, as part of the tree has already been dropped,
>>>>>
>>>>> and this is expected.
>>>>>
>>>>> So far your fs is still OK, except that reported error.
>>>>>
>>>>> -   About the offending tree block
>>>>>
>>>>>      The offending tree block only belongs to the delete subvolume 363,
>>>>>
>>>>>      thus it should be delete soon.
>>>>>
>>>>>
>>>>> But unfortunately due to the corrupted content, it's unable to be
>>>>>
>>>>> deleted.
>>>>>
>>>>> For now, if you can re-compile btrfs module, we can workaround the
>>>>>
>>>>> problem by temporarily disable read-time tree-checker so that the
>>>>>
>>>>> deletion can continue, and after the root 363 get fully deleted, the
>>>>>
>>>>> problem should be gone.
>>>>>
>>>>> Or you can use older kernel, any kernel <= v5.1 should not have the
>>>>>
>>>>> enhanced check, thus can continue with the subvolume deletion.
>>>>>
>>>>> If you want to go through the re-compile path, the needed diff is
>>>>>
>>>>> attached
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Qu
>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Lester
>>>>>>
>>>>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>>>>>
>>>>>> On Saturday, July 17th, 2021 at 8:51 PM,
>>>>>>
>>>>>> pepperpoint@mb.ardentcoding.com wrote:
>>>>>>
>>>>>>> Hi Qu,
>>>>>>>
>>>>>>> I run btrfs ins dump-tree -t 363 unmounted but the same error
>>>>>>>
>>>>>>> appears. Rerunning btrfs check does not show any error.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Lester
>>>>>>>
>>>>>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>>>>>>
>>>>>>> On Saturday, July 17th, 2021 at 6:48 PM, Qu Wenruo -
>>>>>>>
>>>>>>> quwenruo.btrfs@gmx.com wrote:
>>>>>>>
>>>>>>>> On 2021/7/17 下午6:34, pepperpoint@mb.ardentcoding.com wrote:
>>>>>>>>
>>>>>>>>> Hi Qu,
>>>>>>>>>
>>>>>>>>> Unfortunately I cannot find subvolume 363
>>>>>>>>>
>>>>>>>>> btrfs subvolume list /run/media/root
>>>>>>>>> ====================================
>>>>>>>>>
>>>>>>>>> ID 361 gen 1814826 top level 584 path @/live/snapshot
>>>>>>>>>
>>>>>>>>> ID 364 gen 1814414 top level 5 path @vtmp/live/snapshot
>>>>>>>>>
>>>>>>>>> ID 369 gen 1814414 top level 5 path @vlmachines/live/snapshot
>>>>>>>>>
>>>>>>>>> ID 493 gen 1814414 top level 5 path @vlportables/live/snapshot
>>>>>>>>>
>>>>>>>>> ID 579 gen 1814828 top level 5 path @vlog/live/snapshot
>>>>>>>>>
>>>>>>>>> ID 580 gen 1814414 top level 5 path @vcache/live/snapshot
>>>>>>>>>
>>>>>>>>> ID 581 gen 1814414 top level 5 path @vlmongodb/live/snapshot
>>>>>>>>>
>>>>>>>>> ID 582 gen 1814414 top level 5 path @vlmysql/live/snapshot
>>>>>>>>>
>>>>>>>>> ID 583 gen 1814414 top level 5 path @vspool/live/snapshot
>>>>>>>>>
>>>>>>>>> ID 584 gen 1814414 top level 5 path @
>>>>>>>>>
>>>>>>>>> ID 598 gen 1813420 top level 584 path @/4/snapshot
>>>>>>>>
>>>>>>>> Maybe 363 is some subvolume get deleted and later snapshot of it still
>>>>>>>>
>>>>>>>> exists.
>>>>>>>>
>>>>>>>> This will be harder to debug.
>>>>>>>>
>>>>>>>> Can you take a btrfs-image dump of your filesystem? (needs to be taken
>>>>>>>>
>>>>>>>> with the fs unmounted).
>>>>>>>>
>>>>>>>> The dumped image will contain your metadata, including file names and
>>>>>>>>
>>>>>>>> directory structures, but no data inside those files.
>>>>>>>>
>>>>>>>> Although btrfs-image has "-s" option to mask the filenames, but
>>>>>>>>
>>>>>>>> considering the filename in this case is useful to locate the inode, I
>>>>>>>>
>>>>>>>> guess it's better to take the image without any "-s" option.
>>>>>>>>
>>>>>>>>> btrfs ins dump-tree -t 363 /dev/dm-0 | grep -A 5 "(286 "
>>>>>>>>> ========================================================
>>>>>>>>>
>>>>>>>>> parent transid verify failed on 174170742784 wanted 1789655 found
>>>>>>>>>
>>>>>>>>> 1812621
>>>>>>>>>
>>>>>>>>> parent transid verify failed on 174170742784 wanted 1789655 found
>>>>>>>>>
>>>>>>>>> 1812621
>>>>>>>>>
>>>>>>>>> parent transid verify failed on 174170742784 wanted 1789655 found
>>>>>>>>>
>>>>>>>>> 1812621
>>>>>>>>>
>>>>>>>>> Ignoring transid failure
>>>>>>>>>
>>>>>>>>> ERROR: child eb corrupted: parent bytenr=174170738688 item=0 parent
>>>>>>>>>
>>>>>>>>> level=2 child bytenr=174170742784 child level=0
>>>>>>>>
>>>>>>>> This transid mismatch may be a problem when running dump-tree on
>>>>>>>>
>>>>>>>> mounted
>>>>>>>>
>>>>>>>> fs, since you mentioned btrfs check reported no error, there shouldn't
>>>>>>>>
>>>>>>>> be a transid mismatch error.
>>>>>>>>
>>>>>>>> Anyway, if you can upload the btrfs-image dump, it would be much easier
>>>>>>>>
>>>>>>>> for us to debug and find out what's really going.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Qu
>>>>>>>>
>>>>>>>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>>>>>>>>
>>>>>>>>> On Saturday, July 17th, 2021 at 6:12 PM, Qu Wenruo wqu@suse.com wrote:
>>>>>>>>>
>>>>>>>>>> On 2021/7/17 下午4:57, pepperpoint@mb.ardentcoding.com wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Qu,
>>>>>>>>>>>
>>>>>>>>>>> I don't know how the directory was created but last month, I used
>>>>>>>>>>>
>>>>>>>>>>> btrfs device add and btrfs device remove to move the filesystem
>>>>>>>>>>>
>>>>>>>>>>> from one partition to another. It failed because of the same
>>>>>>>>>>>
>>>>>>>>>>> error and was advised to use btrfs replace instead. I don't know
>>>>>>>>>>>
>>>>>>>>>>> if the error also happened before I move the file system as I
>>>>>>>>>>>
>>>>>>>>>>> don't have any previous logs.
>>>>>>>>>>
>>>>>>>>>> It definitely happens before you moving the fs.
>>>>>>>>>>
>>>>>>>>>> As regular dev replacing/add/move only relocates the metadata, but
>>>>>>>>>>
>>>>>>>>>> not
>>>>>>>>>>
>>>>>>>>>> touching the fs trees.
>>>>>>>>>>
>>>>>>>>>>> Here is the result when I search for the inodes you mentioned if
>>>>>>>>>>>
>>>>>>>>>>> it helps:
>>>>>>>>>>>
>>>>>>>>>>> find /run/media/root -inum 260 -exec ls -ldi {} \;
>>>>>>>>>>> ==================================================
>>>>>>>>>>>
>>>>>>>>>>> 260 -rw-r--r-- 1 root root 36864 Jun 25 06:22
>>>>>>>>>>>
>>>>>>>>>>> /run/media/root/@vcache/live/snapshot/app-info/cache/en_US.cache
>>>>>>>>>>>
>>>>>>>>>>> 260 drwx------ 1 mongodb mongodb 136 Sep 12 2020
>>>>>>>>>>>
>>>>>>>>>>> /run/media/root/@vlmongodb/live/snapshot/diagnostic.data
>>>>>>>>>>>
>>>>>>>>>>> 260 -rw-rw---- 1 mysql mysql 50331648 Sep 13 2015
>>>>>>>>>>>
>>>>>>>>>>> /run/media/root/@vlmysql/live/snapshot/ib_logfile0
>>>>>>>>>>>
>>>>>>>>>>> 260 -rw-r----- 1 root lp 8641 Mar 5 2014
>>>>>>>>>>>
>>>>>>>>>>> /run/media/root/@vspool/live/snapshot/cups/d00001-001
>>>>>>>>>>>
>>>>>>>>>>> 260 dr-xr-xr-x 1 root root 0 Sep 13 2013
>>>>>>>>>>>
>>>>>>>>>>> /run/media/root/@/live/snapshot/sys
>>>>>>>>>>>
>>>>>>>>>>> 260 dr-xr-xr-x 1 root root 0 Sep 13 2013
>>>>>>>>>>>
>>>>>>>>>>> /run/media/root/@/4/snapshot/sys
>>>>>>>>>>
>>>>>>>>>> Since btrfs can have the same inode number inside different
>>>>>>>>>>
>>>>>>>>>> subvolumes,
>>>>>>>>>>
>>>>>>>>>> you may want to limit the search inside subvolume 363.
>>>>>>>>>>
>>>>>>>>>> "-mount" option of find can do that, you only need to locate
>>>>>>>>>>
>>>>>>>>>> subvolume
>>>>>>>>>>
>>>>>>>>>> 363 by "btrfs subv list".
>>>>>>>>>>
>>>>>>>>>> But from these output I guess above two "sys" directory are more
>>>>>>>>>>
>>>>>>>>>> possible.
>>>>>>>>>>
>>>>>>>>>> Is there any directory named "blaklight" inside those directory?
>>>>>>>>>>
>>>>>>>>>>> find /run/media/root -inum 286 -exec ls -ldi {} \;
>>>>>>>>>>> ==================================================
>>>>>>>>>>>
>>>>>>>>>>> 286 -rw-r--r-- 1 root root 96 Aug 16 2015
>>>>>>>>>>>
>>>>>>>>>>> /run/media/root/@vcache/live/snapshot/fontconfig/4b172ca7f111e3cffadc3636415fead9-le64.cache-4
>>>>>>>>>>>
>>>>>>>>>>> 286 -rw-rw---- 1 mysql mysql 4096 Sep 15 2013
>>>>>>>>>>>
>>>>>>>>>>> /run/media/root/@vlmysql/live/snapshot/mysql/columns_priv.MYI
>>>>>>>>>>>
>>>>>>>>>>> 286 -rw-r-----+ 1 root systemd-journal 16777216 Jul 4 01:14
>>>>>>>>>>>
>>>>>>>>>>> /run/media/root/@vlog/live/snapshot/journal/5098dd7845ae46d3ba1826c68a809a7c/user-1000@fbd9f65d0ea349f6b996716280e6c4dd-00000000002314c5-0005c5cb84a3a438.journal
>>>>>>>>>>
>>>>>>>>>> This is interesting, it means the inode 286 is not accessible.
>>>>>>>>>>
>>>>>>>>>> It can be some orphan inode, but would you dump subvolume 363 then
>>>>>>>>>>
>>>>>>>>>> try
>>>>>>>>>>
>>>>>>>>>> to locate the inode 286?
>>>>>>>>>>
>>>>>>>>>> One example command would be:
>>>>>>>>>>
>>>>>>>>>> btrfs ins dump-tree -t 363 <dev> | grep -A 5 "(286 "
>>>>>>>>>> ====================================================
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Qu
>>>>>>>>>>
>>>>>>>>>>> Directories with pattern /root/@<dir>/live/snapshot/ are
>>>>>>>>>>>
>>>>>>>>>>> subvolumes and directories with pattern
>>>>>>>>>>>
>>>>>>>>>>> /root/@<dir>/<num>/snapshot/ are snapshots of live.
>>>>>>>>>>>
>>>>>>>>>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>>>>>>>>>>
>>>>>>>>>>> On Saturday, July 17th, 2021 at 4:14 PM, Qu Wenruo
>>>>>>>>>>>
>>>>>>>>>>> quwenruo.btrfs@gmx.com wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 2021/7/17 下午3:51, pepperpoint@mb.ardentcoding.com wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Qu,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please see below for the dump.
>>>>>>>>>>>>>
>>>>>>>>>>>>> btrfs-progs v5.12.1
>>>>>>>>>>>>>
>>>>>>>>>>>>> leaf 174113599488 items 18 free space 2008 generation 1330906
>>>>>>>>>>>>>
>>>>>>>>>>>>> owner 363
>>>>>>>>>>>>>
>>>>>>>>>>>>> leaf 174113599488 flags 0x1(WRITTEN) backref revision 1
>>>>>>>>>>>>>
>>>>>>>>>>>>> fs uuid a7d327c4-8594-4116-a6f8-8aa2a4162063
>>>>>>>>>>>>>
>>>>>>>>>>>>> chunk uuid f885f49e-14a0-4c80-9c12-c2302b9a0229
>>>>>>>>>>>>>
>>>>>>>>>>>>> item 0 key (5471 INODE_ITEM 0) itemoff 3835 itemsize 160
>>>>>>>>>>>>>
>>>>>>>>>>>>> generation 2063 transid 27726 size 40 nbytes 40
>>>>>>>>>>>>>
>>>>>>>>>>>>> block group 0 mode 100600 links 1 uid 0 gid 100 rdev 0
>>>>>>>>>>>>>
>>>>>>>>>>>>> sequence 1501 flags 0x0(none)
>>>>>>>>>>>>>
>>>>>>>>>>>>> atime 1386484844.468769570 (2013-12-08 14:40:44)
>>>>>>>>>>>>>
>>>>>>>>>>>>> ctime 1386484844.468769570 (2013-12-08 14:40:44)
>>>>>>>>>>>>>
>>>>>>>>>>>>> mtime 1386484844.468769570 (2013-12-08 14:40:44)
>>>>>>>>>>>>>
>>>>>>>>>>>>> otime 0.0 (1970-01-01 08:00:00)
>>>>>>>>>>>>>
>>>>>>>>>>>>> item 1 key (5471 INODE_REF 4399) itemoff 3824 itemsize 11
>>>>>>>>>>>>>
>>>>>>>>>>>>> index 12 namelen 1 name: 8
>>>>>>>>>>>>>
>>>>>>>>>>>>> item 2 key (5471 EXTENT_DATA 0) itemoff 3763 itemsize 61
>>>>>>>>>>>>>
>>>>>>>>>>>>> generation 27726 type 0 (inline)
>>>>>>>>>>>>>
>>>>>>>>>>>>> inline extent data size 40 ram_bytes 40 compression 0 (none)
>>>>>>>>>>>>>
>>>>>>>>>>>>> item 3 key (5645 INODE_ITEM 0) itemoff 3603 itemsize 160
>>>>>>>>>>>>>
>>>>>>>>>>>>> generation 2542 transid 61261 size 40 nbytes 40
>>>>>>>>>>>>>
>>>>>>>>>>>>> block group 0 mode 100600 links 1 uid 0 gid 100 rdev 0
>>>>>>>>>>>>>
>>>>>>>>>>>>> sequence 24769 flags 0x0(none)
>>>>>>>>>>>>>
>>>>>>>>>>>>> atime 1394335806.351857522 (2014-03-09 11:30:06)
>>>>>>>>>>>>>
>>>>>>>>>>>>> ctime 1394335827.344389955 (2014-03-09 11:30:27)
>>>>>>>>>>>>>
>>>>>>>>>>>>> mtime 1394335827.344389955 (2014-03-09 11:30:27)
>>>>>>>>>>>>>
>>>>>>>>>>>>> otime 0.0 (1970-01-01 08:00:00)
>>>>>>>>>>>>>
>>>>>>>>>>>>> item 4 key (5645 INODE_REF 4399) itemoff 3592 itemsize 11
>>>>>>>>>>>>>
>>>>>>>>>>>>> index 13 namelen 1 name: 7
>>>>>>>>>>>>>
>>>>>>>>>>>>> item 5 key (5645 EXTENT_DATA 0) itemoff 3531 itemsize 61
>>>>>>>>>>>>>
>>>>>>>>>>>>> generation 61261 type 0 (inline)
>>>>>>>>>>>>>
>>>>>>>>>>>>> inline extent data size 40 ram_bytes 40 compression 0 (none)
>>>>>>>>>>>>>
>>>>>>>>>>>>> item 6 key (7222 INODE_ITEM 0) itemoff 3371 itemsize 160
>>>>>>>>>>>>>
>>>>>>>>>>>>> generation 5754 transid 5767 size 307 nbytes 307
>>>>>>>>>>>>>
>>>>>>>>>>>>> block group 0 mode 100644 links 1 uid 0 gid 0 rdev 0
>>>>>>>>>>>>>
>>>>>>>>>>>>> sequence 7 flags 0x0(none)
>>>>>>>>>>>>>
>>>>>>>>>>>>> atime 1379834835.428558020 (2013-09-22 15:27:15)
>>>>>>>>>>>>>
>>>>>>>>>>>>> ctime 1379834835.428558020 (2013-09-22 15:27:15)
>>>>>>>>>>>>>
>>>>>>>>>>>>> mtime 1379834835.428558020 (2013-09-22 15:27:15)
>>>>>>>>>>>>>
>>>>>>>>>>>>> otime 0.0 (1970-01-01 08:00:00)
>>>>>>>>>>>>>
>>>>>>>>>>>>> item 7 key (7222 INODE_REF 287) itemoff 3344 itemsize 27
>>>>>>>>>>>>>
>>>>>>>>>>>>> index 6 namelen 17 name: dhcpcd-eth0.lease
>>>>>>>>>>>>>
>>>>>>>>>>>>> item 8 key (7222 EXTENT_DATA 0) itemoff 3016 itemsize 328
>>>>>>>>>>>>>
>>>>>>>>>>>>> generation 5767 type 0 (inline)
>>>>>>>>>>>>>
>>>>>>>>>>>>> inline extent data size 307 ram_bytes 307 compression 0 (none)
>>>>>>>>>>>>>
>>>>>>>>>>>>> item 9 key (7415 INODE_ITEM 0) itemoff 2856 itemsize 160
>>>>>>>>>>>>>
>>>>>>>>>>>>> generation 5904 transid 1330906 size 180 nbytes 0
>>>>>>>>>>>>>
>>>>>>>>>>>>> block group 0 mode 40755 links 2 uid 0 gid 0 rdev 0
>>>>>>>>>>>>>
>>>>>>>>>>>>> sequence 177 flags 0x0(none)
>>>>>>>>>>>>>
>>>>>>>>>>>>> atime 1483277713.141980592 (2017-01-01 21:35:13)
>>>>>>>>>>>>>
>>>>>>>>>>>>> ctime 1563162901.234656246 (2019-07-15 11:55:01)
>>>>>>>>>>>>>
>>>>>>>>>>>>> mtime 1406534032.158605559 (2014-07-28 15:53:52)
>>>>>>>>>>>>>
>>>>>>>>>>>>> otime 0.0 (1970-01-01 08:00:00)
>>>>>>>>>>>>
>>>>>>>>>>>> This inode is indeed a directory.
>>>>>>>>>>>>
>>>>>>>>>>>> But it has two hard links, which is definitely something
>>>>>>>>>>>>
>>>>>>>>>>>> unexpected.
>>>>>>>>>>>>
>>>>>>>>>>>> Under Linux we shouldn't have any hardlink for directory, as it
>>>>>>>>>>>>
>>>>>>>>>>>> would
>>>>>>>>>>>>
>>>>>>>>>>>> easily lead to loops.
>>>>>>>>>>>>
>>>>>>>>>>>>> item 10 key (7415 INODE_REF 260) itemoff 2837 itemsize 19
>>>>>>>>>>>>>
>>>>>>>>>>>>> index 28 namelen 9 name: backlight
>>>>>>>>>>>>
>>>>>>>>>>>> Its parent inode is 260 in the same root, with the name backlight.
>>>>>>>>>>>>
>>>>>>>>>>>>> item 11 key (7415 INODE_REF 286) itemoff 2818 itemsize 19
>>>>>>>>>>>>>
>>>>>>>>>>>>> index 3 namelen 9 name: backlight
>>>>>>>>>>>>
>>>>>>>>>>>> Another hardlink in inode 286, which is definitely a regular thing.
>>>>>>>>>>>>
>>>>>>>>>>>> Btrfs-progs lacks the ability to detect such problem, we need to
>>>>>>>>>>>>
>>>>>>>>>>>> enhance
>>>>>>>>>>>>
>>>>>>>>>>>> it first.
>>>>>>>>>>>>
>>>>>>>>>>>> But do you have any idea how this directory get created?
>>>>>>>>>>>>
>>>>>>>>>>>> It looks like the content of sysfs.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> Qu
>>>>>>>>>>>>
>>>>>>>>>>>>> item 12 key (7415 DIR_ITEM 3128336373) itemoff 2746 itemsize 72
>>>>>>>>>>>>>
>>>>>>>>>>>>> location key (120417 INODE_ITEM 0) type FILE
>>>>>>>>>>>>>
>>>>>>>>>>>>> transid 117279 data_len 0 name_len 42
>>>>>>>>>>>>>
>>>>>>>>>>>>> name: pci-0000:00:02.0:backlight:intel_backlight
>>>>>>>>>>>>>
>>>>>>>>>>>>> item 13 key (7415 DIR_ITEM 3218198317) itemoff 2705 itemsize 41
>>>>>>>>>>>>>
>>>>>>>>>>>>> location key (7487 INODE_ITEM 0) type FILE
>>>>>>>>>>>>>
>>>>>>>>>>>>> transid 5992 data_len 0 name_len 11
>>>>>>>>>>>>>
>>>>>>>>>>>>> name: acpi_video0
>>>>>>>>>>>>>
>>>>>>>>>>>>> item 14 key (7415 DIR_ITEM 3582254411) itemoff 2638 itemsize 67
>>>>>>>>>>>>>
>>>>>>>>>>>>> location key (55325 INODE_ITEM 0) type FILE
>>>>>>>>>>>>>
>>>>>>>>>>>>> transid 63351 data_len 0 name_len 37
>>>>>>>>>>>>>
>>>>>>>>>>>>> name: platform-VPC2004:00:backlight:ideapad
>>>>>>>>>>>>>
>>>>>>>>>>>>> item 15 key (7415 DIR_INDEX 2) itemoff 2597 itemsize 41
>>>>>>>>>>>>>
>>>>>>>>>>>>> location key (7487 INODE_ITEM 0) type FILE
>>>>>>>>>>>>>
>>>>>>>>>>>>> transid 5992 data_len 0 name_len 11
>>>>>>>>>>>>>
>>>>>>>>>>>>> name: acpi_video0
>>>>>>>>>>>>>
>>>>>>>>>>>>> item 16 key (7415 DIR_INDEX 4) itemoff 2530 itemsize 67
>>>>>>>>>>>>>
>>>>>>>>>>>>> location key (55325 INODE_ITEM 0) type FILE
>>>>>>>>>>>>>
>>>>>>>>>>>>> transid 63351 data_len 0 name_len 37
>>>>>>>>>>>>>
>>>>>>>>>>>>> name: platform-VPC2004:00:backlight:ideapad
>>>>>>>>>>>>>
>>>>>>>>>>>>> item 17 key (7415 DIR_INDEX 5) itemoff 2458 itemsize 72
>>>>>>>>>>>>>
>>>>>>>>>>>>> location key (120417 INODE_ITEM 0) type FILE
>>>>>>>>>>>>>
>>>>>>>>>>>>> transid 117279 data_len 0 name_len 42
>>>>>>>>>>>>>
>>>>>>>>>>>>> name: pci-0000:00:02.0:backlight:intel_backlight
>>>>>>>>>>>>>
>>>>>>>>>>>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Saturday, July 17th, 2021 at 3:05 PM, Qu Wenruo
>>>>>>>>>>>>>
>>>>>>>>>>>>> quwenruo.btrfs@gmx.com wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2021/7/17 上午9:45, pepperpoint@mb.ardentcoding.com wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I see this message on dmesg:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [ 2452.256756] BTRFS critical (device dm-0): corrupt leaf:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> root=363 block=174113599488 slot=9 ino=7415, invalid nlink:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> has 2 expect no more than 1 for dir
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [ 2452.256776] BTRFS error (device dm-0): block=174113599488
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> read time tree block corruption detected
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please provide the following dump:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> btrfs ins dump-tree -b 174113599488 /dev/dm-0
>>>>>>>>>>>>>> =============================================
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Qu
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When I run btrfs scrub and btrfs check, no error was detected.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I am running Linux 5.12.15-arch1-1 and btrfs-progs v5.12.1
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> How should I fix this error?