On 2019/10/16 下午3:42, Nikolay Borisov wrote: > > > On 16.10.19 г. 3:43 ч., Qu Wenruo wrote: >> >> >> On 2019/10/16 上午1:55, José Luis wrote: >>> I also noticed the craziness of the previous dump. I cannot remember >>> the kernel running by this date but I use to install the latest stable >>> kernel on the Manjaro repositories (I'm an early adopter :P). >>> According the Manjaro forum release news they roll up version 4.19 by >>> these days so probably I was using kernel 4.19 or 4.18. Diggin on my >>> memory, maybe I could access that filesystem from a Windows 10 running >>> on another disk using the windows btrfs driver that could be the >>> origin of the problem. >> >> That explains the problem why there are some strange windows related file. >> >> And that also explains why kernel tree-checker isn't happy about that at >> all. >> Maybe Windows btrfs driver is using some strange inode number to do its >> own work, but definitely not something friendly to upstream btrfs. >> >> You may want to report the bug to windows btrfs developers. >> >>> >>> I added a \s to the pattern you provided to avoid undesired inode information: >>> [manjaro@manjaro ~]$ sudo btrfs ins dump-tree -t 5 /dev/sdb2 | grep "(431 " -A 7 >>> output --> https://pastebin.com/y3LzqNx6 >> >> I see no obvious problem. Maybe some compressed data extent doesn't have >> csum, then btrfs check reports it as bad file extent. >> >> Original mode doesn't report info as detailed as possible. >> But anyway, it shouldn't be a big problem. >> >> If you're not confident about it, you can try to defrag those inodes, it >> should rewrite them and populate the csum. >> >>> >>> Is there any magic command to repair my sdb2 filesystem? Or I have to >>> backup data and rebuild those filesystems? >> >> In fact it's not that hard to repair, just remove the offending craziness. >> >> btrfs-corrupt-block should provide the ability to delete items. >> It a tool included in btrfs-progs, but not provided in btrfs-progs >> packages. You may need to compile it from source code. >> >> In your case, you need quite some calls to delete all the bad inodes: >> >> /* FREE_INO INODE_ITEM 0 */ >> # ./btrfs-corrupt-block -d 18446744073709551604,1,0 /dev/sdb2 >> >> /* FREE_SPACE UNTYPED 0 */ >> # ./btrfs-corrupt-block -d 18446744073709551605,0,0 /dev/sdb2 >> >> ... >> >> And so on. You need to parse the key output to numeric value and pass it >> to btrfs-corrupt-block, until all finished. >> >> If it's too slow, I could add a new hack into btrfs-corrupt-block to >> delete them in a batch. > > Please don't. btrfs-corrupt-block is supposed to aid development not fix > user problems. If it can fix them, by accident, then OK but it shouldn't > be cluttered with code used in some _very_ specific cases. > > You can provide this code on your own accord but let's not merge it into > the upstream btrfs-corrupt-block source code. Of course, just as my usual dirty fixes (a special branch for the user to do, never intended to upstream). Thanks, Qu > > <snip> >
