Re: Unable to remove directory entry

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

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



On 2019/12/9 上午10:37, Mike Gilbert wrote:
> On Sun, Dec 8, 2019 at 9:20 PM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>
>>
>>
>> On 2019/12/9 上午10:05, Qu Wenruo wrote:
>>>
>>>
>>> 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.
>>
>> Here is the special branch for you:
>> https://github.com/adam900710/btrfs-progs/tree/dirty_fix_for_mike
>>
>> After compile, you can use btrfs-corrupt-block (I know it's a bad name)
>> to repair your fs (must be unmounted):
>>
>> # ./btrfs-corrupt-block -X /dev/sda3
>>
>> If anything wrong happened, your fs should be kept untouched.
>> If repaired successfully, there should be no output.
>>
>> Thanks,
>> Qu
> 
> That worked. Thank you very much for your help with this!
> 
> Now, I guess I'll fire up Memtest86 overnight.
> 
Just a reminder, if tree-checker is properly enhanced, for 5.6 even with
bad memory, we should be able to detect and prevent it in advance.

Thanks,
Qu


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