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. <snip>
