On 2018年01月16日 12:51, Qu Wenruo wrote:
> Now the problems are all located:
> 
> For file "2f3f379b2a3d7499471edb74869efe-1948311.d", it's the problem of
> its DIR_ITEM has wrong type:
> 
> ------
>         item 14 key (57648595 DIR_ITEM 3363354030) itemoff 3053 itemsize 70
>                 location key (57923894 INODE_ITEM 0) type DIR_ITEM.33
>                                                           ^^^^^^^^^^^
> ------
> 
> There is unexpected type DIR_ITEM and a special number 33 here.
> 
> Despite that, the file is completely fine.
> 
> 
> For file "454bf066ddfbf42e0f3b77ea71c82f-878732.o"
> The problem is its namelen.
> 
> ------
>         item 13 key (57648595 DIR_ITEM 3331247447) itemoff 3123 itemsize 69
>                 location key (58472210 INODE_ITEM 0) type FILE
>                 transid 89418 data_len 0 name_len 8231
>                                                   ^^^^ Insane
>                 name: 454bf066ddfbf42e0f3b77ea71c82f-878732.oq
> ------
> 
> Despite that, it should be fine.
> 
> I'm not 100% sure if repair can really handle it well.
> But I could craft a temporary fix based on btrfs-corrupt-block (I know
> the name is scary).
> And you may need to compile btrfs-progs with my patch.

I just assume it's fs_root, and pushed the hard-coded fix branch to my
github:
https://github.com/adam900710/btrfs-progs/tree/hard_coded_fix_for_sebastian

Usage:
./btrfs-corrupt-block -X <device>

Just as commit message says, if anything went wrong, it will not touch
the fs at all.
So it should be somewhat safe to use.

And if something went wrong, it will cause backtrace and abort, it's
designed and you don't need to panic:

Example: No dir_item in my btrfs
------
./btrfs-corrupt-block -X /dev/data/btrfs
ERROR: corrupted DIR_ITEM not found
extent buffer leak: start 4227072 len 16384
extent_io.c:607: free_extent_buffer_internal: BUG_ON `eb->flags &
EXTENT_DIRTY` triggered, value 1
./btrfs-corrupt-block(+0x251df)[0x5623e003a1df]
./btrfs-corrupt-block(free_extent_buffer_nocache+0x1f)[0x5623e003aac1]
./btrfs-corrupt-block(extent_io_tree_cleanup+0x6d)[0x5623e003ab33]
./btrfs-corrupt-block(btrfs_cleanup_all_caches+0x76)[0x5623e0027747]
./btrfs-corrupt-block(close_ctree_fs_info+0x111)[0x5623e0028027]
./btrfs-corrupt-block(main+0x3f5)[0x5623e00551df]
/usr/lib/libc.so.6(__libc_start_main+0xea)[0x7fdce4e0ff4a]
./btrfs-corrupt-block(_start+0x2a)[0x5623e001ee3a]
Aborted (core dumped)
------

And if above error happens, please paste the error output and provide
the subvolume id.

Thanks,
Qu

> 
> The only remaining thing I need is the subvolume id which contains the
> corrupted files.
> 
> Since there is no other hit, I assume it's root subvolume (5), but I
> still need the extra confirm since the fix will be hard-coded.
> 
> Thanks,
> Qu
> 

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to