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

["^m'e" <marcoep@gmail.com>]

Thanks Qu!

I did it (had to add 'progs_extra' to the 'static' make target...),
but it looks like there's something missing:

-------------------------------------------------------------
# ./btrfs-corrupt-block.static -X /dev/sdb3
./btrfs-corrupt-block.static: invalid option -- 'X'
usage: btrfs-corrupt-block [options] device
    -l Logical extent to be corrupted
    -c Copy of the extent to be corrupted (usually 1 or 2, default: 0)
    -b Number of bytes to be corrupted
    -e Extent to be corrupted
    -E The whole extent tree to be corrupted
    -u Given chunk item to be corrupted
    -U The whole chunk tree to be corrupted
    -i The inode item to corrupt (must also specify the field to corrupt)
    -x The file extent item to corrupt (must also specify -i for the
inode and -f for the field to corrupt)
    -m The metadata block to corrupt (must also specify -f for the
field to corrupt)
    -K The key to corrupt in the format <num>,<num>,<num> (must also
specify -f for the field)
    -f The field in the item to corrupt
    -I An item to corrupt (must also specify the field to corrupt and
a root+key for the item)
    -D Corrupt a dir item, must specify key and field
    -d Delete this item (must specify -K)
-------------------------------------------------------------

I cloned at --depth=1, if that matters... Didn't dare to play around
wiht the lowercase 'x' option... O_o


On Wed, Jan 24, 2018 at 10:14 AM, Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
> Here is the super dirty tricky fix (and less deadly now).
>
> https://github.com/adam900710/btrfs-progs/tree/dirty_fix
>
> Please compile the branch and run:
>
> # ./btrfs-corrupt-block -X <device>
>
> Where <device> must be unmounted, the original btrfs-corrupt-block tool
> doesn't have mount check, and I'm too lazy to add such check.
>
> The hack will remove the offending DIR_ITEM completely, and unlink the
> old "Manifest" file, and repair the link for newer "Manifest" file.
>
> And it shouldn't write anything to disk if any operation failed, so it's
> less deadly.
>
> Wish you good luck.
>
> Thanks,
> Qu
>
> On 2018年01月24日 17:18, Foo Bar wrote:
>> 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
>>>
>>
>



-- 
^m'e