Re: Unable to remove directory entry

From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Mike Gilbert <floppymaster@gmail.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Unable to remove directory entry
Date: Mon, 9 Dec 2019 10:05:02 +0800	[thread overview]
Message-ID: <d954ccdb-ac9a-1209-130c-e3b34e4a7a45@gmx.com> (raw)
In-Reply-To: <CAJ0EP40UUPe9VrF1x8mxnEhFxiTzgC9DkQZB684UuMF1571D+Q@mail.gmail.com>

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

On 2019/12/9 上午9:51, Mike Gilbert wrote:
[...]
> 
> Here you go.
> 
> I ran this while the filesystem was mounted; if you need it to be run
> while offline, I'll have to fire up a livecd.
The info is good enough, no need to go livecd.

> --
>        item 6 key (4065004 INODE_ITEM 0) itemoff 15158 itemsize 160
>                generation 21397 transid 21397 size 12261 nbytes 12288
>                block group 0 mode 100644 links 1 uid 250 gid 250 rdev 0
>                sequence 23 flags 0x0(none)
>                atime 1565546668.383680243 (2019-08-11 14:04:28)
>                ctime 1565546668.383680243 (2019-08-11 14:04:28)
>                mtime 1565546668.383680243 (2019-08-11 14:04:28)
>                otime 1565546668.336681213 (2019-08-11 14:04:28)
>        item 7 key (4065004 INODE_REF 486836) itemoff 15104 itemsize 54
>                index 13905 namelen 44 name:
> 0390cb341d248c589c419007da68b2-7351.manifest

That inode exists and is good.

>        item 8 key (4065004 EXTENT_DATA 0) itemoff 15051 itemsize 53
>                generation 21397 type 1 (regular)
>                extent data disk byte 6288928768 nr 12288
>                extent data offset 0 nr 12288 ram 12288
>                extent compression 0 (none)
>        item 9 key (4210974 INODE_ITEM 0) itemoff 14891 itemsize 160
>        item 63 key (486836 DIR_INDEX 13905) itemoff 6199 itemsize 74
>                location key (4065004 INODE_ITEM 0) type FILE
>                transid 21397 data_len 0 name_len 44
>                name: 0390cb341d248c589c419007da68b2-7351.manifest

Good parent dir index.

> leaf 533498265600 items 128 free space 6682 generation 176439 owner FS_TREE
> leaf 533498265600 flags 0x1(WRITTEN) backref revision 1
> fs uuid 5e9dcab6-036d-40f1-8b40-24ab4c062bf6
> chunk uuid 0be705de-5d3b-4c23-979e-d7aaad224cfb
>        item 62 key (486836 DIR_ITEM 2543451757) itemoff 6273 itemsize 74
>                location key (4065004 INODE_ITEM 1073741824) type FILE
>                transid 21397 data_len 0 name_len 44
>                name: 0390cb341d248c589c419007da68b2-7351.manifest

This is the problem, bad parent dir hash.

The key should be (4065004 INODE_ITEM 0). The 1073741824 (0x40000000) is
completely garbage.

That garbage looks like a bit flip at runtime.
It's recommended to check your memory.

I'll add extra tree-check checks, so that such runtime problem can be
detected before corrupted data reach disk.

For repair, I'll craft a special btrfs-progs for you to handle it, as
that should be the safest way.
Please wait for another 15min for that tool.

Thanks,
Qu

>        item 63 key (486836 DIR_INDEX 13905) itemoff 6199 itemsize 74
>                location key (4065004 INODE_ITEM 0) type FILE
>                transid 21397 data_len 0 name_len 44
>                name: 0390cb341d248c589c419007da68b2-7351.manifest
> parent transid verify failed on 629293056 wanted 177041 found 177044
> parent transid verify failed on 629293056 wanted 177041 found 177044
> Ignoring transid failure
> 

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