Re: btrfs check: backref lost, mismatch with its hash -- can't repair

[Foo Bar <marcoep@gmail.com>]

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

Qu Wenruo wrote on 2018-01-24 09:49:
> Sorry for the late reply, I was off yesterday.
>

No problem :-)

Booted normally today, system up, but see this (I forgot to stop the snapshot
cron task...)

  [  115.127961] BTRFS error (device sdb3): Send: inconsistent snapshot, found
deleted reference for inode 30039323 without updated inode item, send root is
1399, parent root is 1385

So inode 30039323 looks definitely the bad one. Let's get rid of it and keep
the newest dups, if any, thanks!

Cheers,

  Marco

> On 2018年01月22日 23:04, ^m'e wrote:
>> Thanks for the quick reply, Qu!
>>
>> I forgot to say that I see weird characters in the btrfs check repair
>> in lines "ERROR: DIR_ITEM... name ..." output. Although that can be
>> due to corruption, I seem to remember that a previous version of
>> btrfs-progs I used didn't show that...
>> I also see:
>>
>>    [19428.934684] init_special_inode: bogus i_mode (700) for inode
>> sdb3:18446744073709551361
>>
>> BTW, no sensible names in the debug output, and as far as I can see,
>> it might be all stuff in '[rootfs]/usr/portage': if that's the case,
>> corrupted inodes can be safely removed, as the portage package tree
>> can be easily rebuild. Here you are:
>>
>> ---------------------------------->8-------------------------------------
>> # cat btrfs-debug.30039322.log[snip]
> 
> This where the dir starts.
> 
>>     item 78 key (30039322 INODE_ITEM 0) itemoff 4203 itemsize 160
>>         generation 136248 transid 229515 size 152 nbytes 0
>>         block group 0 mode 40755 links 1 uid 250 gid 250 rdev 0
>>         sequence 0 flags 0xf(none)
>>         atime 1504685599.188061317 (2017-09-06 08:13:19)
>>         ctime 1516557882.551679697 (2018-01-21 18:04:42)
>>         mtime 1516557882.551679697 (2018-01-21 18:04:42)
>>         otime 1504685599.188061317 (2017-09-06 08:13:19)
>>     item 79 key (30039322 INODE_REF 30037720) itemoff 4161 itemsize 42
>>         index 242 namelen 32 name: obs-service-download_src_package
>>     item 80 key (30039322 DIR_ITEM 1076301169) itemoff 4083 itemsize 78
>>         location key (30039325 INODE_ITEM 0) type FILE
>>         transid 136248 data_len 0 name_len 48
>>         name: obs-service-download_src_package-20130318.ebuild
>>     item 81 key (30039322 DIR_ITEM 2438219243) itemoff 4041 itemsize 42
>>         location key (0 UNKNOWN.0 0) type FILE
>>         transid 136192 data_len 0 name_len 12
>>         name: metadata.xml
>>     item 82 key (30039322 DIR_ITEM 4007295565) itemoff 3927 itemsize 114
>>         location key (0 UNKNOWN.0 0) type DIR_ITEM.0
>>         transid 0 data_len 0 name_len 0
>>         name:
>>         location key (0 UNKNOWN.125 72057594038112709) type DIR_ITEM.0
>>         transid 0 data_len 32907 name_len 3
>>         name:
>>         data
> 
> The whole item is corrupted.
> Seems to be a half-written item get flushed to disk.
> 
> I assume this is the DIR_ITEM for *two* Manifest, but that's just
> insane, as we're going to have 2 files with the same name "Manifest"
> 
>>     item 83 key (30039322 DIR_INDEX 2) itemoff 3889 itemsize 38
>>         location key (30039323 INODE_ITEM 0) type FILE
>>         transid 3377699720527872 data_len 0 name_len 8
> 
> The transid seems corrupted too.
> 
> Maybe I need to delete this item too?
> 
>>     item 64 key (47302013 INODE_REF 30039322) itemoff 11278 itemsize 18
>>         index 5 namelen 8 name: Manifest
> 
> Now we do have 2 "Manifest".
> 
> Which one do you prefer to delete?
> 
> The latter one, inode 47302013 seems newer, while previous one, inode
> 30039323 is pretty old.
> 
> Despite that, I didn't see big problem in the dump.
> 
> I'll just craft the dirty fix to delete one inode and the incorrect dir
> index/item.
> 
> Thanks,
> Qu
> 

-- 
              /\        /\
             /  \  _____)/ ____
             \/\/ /     \_/ __ \
                 |  Y Y  \  ___/
                 |__|_|  /\___  >
                       \/     \/
    VoIP-CH .. <0225085743@sip.netvoip.ch>
    VoIP-IT . <0683394229@voip.eutelia.it>
    VoIP-2 ........... <marcoep@ekiga.net>
    VoIP-3 .... <marcoep@sip.linphone.org>
    PSTN CH ............. +41 22 508 57 43
    PSTN IT ............. +39 06 8339 4229
    fax IT .............. +39 06 9838 1481


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