Re: Scrub aborts due to corrupt leaf

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

[-- Attachment #1.1: Type: text/plain, Size: 2993 bytes --]



On 2018/8/27 上午10:32, Larkin Lowrey wrote:
> On 8/26/2018 8:16 PM, Qu Wenruo wrote:
>> Corrupted tree block bytenr matches with the number reported by kernel.
>> You could provide the tree block dump for bytenr 7687860535296, and
>> maybe we could find out what's going wrong and fix it manually.
>>
>> # btrfs ins dump-tree -b 7687860535296 <device>
> 
> Thank you for your reply.
> 
> # btrfs ins dump-tree -b 7687860535296 /dev/Cached/Backups
> btrfs-progs v4.15.1
> leaf free space ret -2002721201, leaf data size 16283, used 2002737484
> nritems 319
> leaf 7687860535296 items 319 free space -2002721201 generation 2862 owner 7
> leaf 7687860535296 flags 0x1(WRITTEN) backref revision 1
> fs uuid acff5096-1128-4b24-a15e-4ba04261edc3
> chunk uuid 0d2fdb5d-00c0-41b3-b2ed-39a5e3bf98aa
>         item 0 key (18446744073650847734 EXTENT_CSUM 8487178285056)
> itemoff 13211 itemsize 3072
>                 range start 8487178285056 end 8487181430784 length 3145728
>         item 1 key (18446744073650880502 EXTENT_CSUM 8487174090752)
> itemoff 10139 itemsize 3072
>                 range start 8487174090752 end 8487177236480 length 3145728
>         item 2 key (18446744073650913270 EXTENT_CSUM 8487167782912)
> itemoff 3251 itemsize 6888
>                 range start 8487167782912 end 8487174836224 length 7053312
>         item 3 key (18446744073651011574 EXTENT_CSUM 8487166103552)
> itemoff 187 itemsize 3064
>                 range start 8487166103552 end 8487169241088 length 3137536
>         item 4 key (58523648 UNKNOWN.0 4115587072) itemoff 0 itemsize 0

Starts from this item, the leaf is definitely corrupted.

>         item 5 key (58523648 UNKNOWN.0 4115058688) itemoff 0 itemsize 0
>         item 6 key (58392576 UNKNOWN.0 4115050496) itemoff 0 itemsize 0
>         item 7 key (58392576 UNKNOWN.0 9160800976331685888) itemoff
> 1325803612 itemsize 1549669347
[snip]
> Segmentation fault (core dumped)
> 
> Can I simply rebuild the csum tree (btrfs check --init-csum-tree)? The
> entire contents of the fs are back-up files that are hashed so I can
> verify that the files are correct.

Yes, I just forgot we have the --init-csum-tree option.

You could try that way, at least from previous check run, there is no
other serious corruption.

> 
>> Please note that this corruption could be caused by bad ram or some old
>> kernel bug.
>> It's recommend to run a memtest if possible.
> 
> The system uses ECC memory and edac-util has not reported any errors.
> However, I will run a memtest anyway.

So it should not be the memory problem.

BTW, what's the current generation of the fs?

# btrfs inspect dump-super <device> | grep generation

The corrupted leaf has generation 2862, I'm not sure how recent did the
corruption happen.

Thanks,
Qu

> 
> Thank you,
> 
> --Larkin


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]