On 2019/9/30 下午2:14, Andrey Ivanov wrote: > On 30.09.2019 7:53, Qu Wenruo wrote: >> [[PROBLEM]] >> It's invalid DIR_ITEM, as the dmesg shows: >> >> [ 49.479561] BTRFS critical (device sda4): corrupt leaf: root=5 >> block=134079905792 slot=0 ino=843063, dir item with invalid data len, >> have 256 expect 0 > > This is the kernel message for /dev/sda4. It is also have some problems, > but it is successfully mounted. I can't mount /dev/sdc1. > > Kernel message for /dev/sdc1: > [ 6.503265] BTRFS info (device sdc1): disk space caching is enabled > [ 6.503266] BTRFS info (device sdc1): has skinny extents > [ 8.890135] BTRFS critical (device sdc1): corrupt leaf: root=2 > block=855738744832 slot=20, unexpected item end, have 15287 expect 15223 > [ 8.899635] BTRFS critical (device sdc1): corrupt leaf: root=2 > block=855738744832 slot=20, unexpected item end, have 15287 expect 15223 This is from extent tree. Please provide the following dump: # btrfs ins dump-tree -b 855738744832 /dev/sdc1 This dump doesn't contain anything other than bytenr. So it should be completely fine to share it. > [ 8.899654] BTRFS error (device sdc1): failed to read block groups: -5 > [ 8.906858] BTRFS error (device sdc1): open_ctree failed > > >> [[EXTRA INFO]] >> Please provide the following dump of that tree block by: >> # btrfs ins dump-tree -b 134079905792 /dev/sda4 > > attached btrfs-ins-dump-tree-134079905792.output Confirmed. It looks like the data_len got some bitflips. In that offending leaf, there is only two data_len and all are one bit flipped. Considering that directory is not that old, it looks like some memory bit flip. It's recommended to do a memtest to ensure it's not memory causing the problem. > > >> [[WORKAROUND]] >> As a workaround, you could try to mount the fs with 4.15 kernel, which >> doesn't have the enhanced sanity check while should be still sane enough. >> >> Then find the directory with inode number 843063, copy all its contents >> to a new directory, then remove the old directory. > > How to find directory with inode number 843063? $ find <mount point> -inum 843063 In your case, it should be a directory with some files named "filterlog.html" and "Sent/sbd" in it. I recommend to do a "btrfs check" on all fses. Thanks, Qu
Attachment:
signature.asc
Description: OpenPGP digital signature
