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.bt...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
