On 2019/10/15 下午11:03, José Luis wrote: > Thanks for fast response Qu. > > I booted into a pendrive live system for the test cause I'm using the > involving fylesystem with kernel 4.19. This time when I mount >> [manjaro@manjaro ~]$ sudo mount /dev/sdb2 /mnt >> mount: /mnt: no se puede leer el superbloque en /dev/sdb2. > and in the dmesg: > [ +30,866472] BTRFS info (device sdb2): disk space caching is enabled > [ +0,017443] BTRFS info (device sdb2): enabling ssd optimizations > [ +0,000637] BTRFS critical (device sdb2): corrupt leaf: root=5 > block=32145457152 slot=99, invalid key objectid: has > 18446744073709551605 expect 6 or [256, 18446744073709551360] or > 18446744073709551604 > [ +0,000002] BTRFS error (device sdb2): block=32145457152 read time > tree block corruption detected > [ +0,000012] BTRFS warning (device sdb2): failed to read fs tree: -5 > [ +0,061995] BTRFS error (device sdb2): open_ctree failed > > So I suppose you need dump output from the block 32145457152 so I pastebin that: > sudo btrfs ins dump-tree -b 32145457152 /dev/sdb2 > output --> https://pastebin.com/ssB5HTn7 The output is way crazier than I thought... I was only expecting some strange inode number, but what I got is completely ridiculous. From item 96, we are having completely impossible inodes. From FREE_INO to DATA_RELOC, even EXTENT_CSUM. All of these are impossible to exist in fs tree. The most strange thing is, they are all last modified in 2019-2-15. Anyway, the tree-checker is doing completely valid behavior for this case. The data is really ridiculous. Any history about the kernel used in that time? I see something only possible in Windows, any clue? > > Please provide the parameter to the grep redirection for: "btrfs ins > dump-tree -t 5 /dev/sdb2 | grep -A 7" My bad, the parameter is "(431" It will output all info about inode 431, so we can make sure what's going wrong. Thanks, Qu > > El mar., 15 oct. 2019 a las 14:38, Qu Wenruo > (<quwenruo.btrfs@xxxxxxx>) escribió: >> >> >> >> On 2019/10/15 下午8:24, Qu Wenruo wrote: >>> >>> >>> On 2019/10/15 下午6:15, José Luis wrote: >>>> Dear devs, >>>> >>>> I cannot use kernel >= 5.2, They cannot mount sdb2 nor sb3 both btrfs >>>> filesystems. I can work as intended on 4.19 which is an LTS version, >>>> previously using 5.1 but Manjaro removed it from their repositories. >>>> >>>> More info: >>>> · dmesg: >>>>> [oct15 13:47] BTRFS info (device sdb2): disk space caching is enabled >>>>> [ +0,009974] BTRFS info (device sdb2): enabling ssd optimizations >>>>> [ +0,000481] BTRFS critical (device sdb2): corrupt leaf: root=5 block=30622793728 slot=115, invalid key objectid: has 18446744073709551605 expect 6 or [256, 18446744073709551360] or 18446744073709551604 >>> >>> In fs tree, you are hitting a free space cache inode? >>> That doesn't sound good. >>> >>> Please provide the following dump: >>> >>> # btrfs ins dump-tree -b 30622793728 /dev/sdb2 >>> >>> The output may contain filename, feel free to remove filenames. >>> >>>>> [ +0,000002] BTRFS error (device sdb2): block=30622793728 read time tree block corruption detected >>>>> [ +0,000021] BTRFS warning (device sdb2): failed to read fs tree: -5 >>>>> [ +0,044643] BTRFS error (device sdb2): open_ctree failed >>>> >>>> >>>> >>>> · sudo mount /dev/sdb2 /mnt/ >>>>> mount: /mnt: no se puede leer el superbloque en /dev/sdb2. >>>> >>>> (cannot read superblock on /dev...) >>>> >>>> · sudo btrfs rescue super-recover /dev/sdb2 >>>>> All supers are valid, no need to recover >>>> >>>> >>>> · sudo btrfs check /dev/sdb2 >>>>> Opening filesystem to check... >>>>> Checking filesystem on /dev/sdb2 >>>>> UUID: ff559c37-bc38-491c-9edc-fa6bb0874942 >>>>> [1/7] checking root items >>>>> [2/7] checking extents >>>>> [3/7] checking free space cache >>>>> cache and super generation don't match, space cache will be invalidated >>>>> [4/7] checking fs roots >>>>> root 5 inode 431 errors 1040, bad file extent, some csum missing >>>>> root 5 inode 755 errors 1040, bad file extent, some csum missing >>>>> root 5 inode 2379 errors 1040, bad file extent, some csum missing >>>>> root 5 inode 11721 errors 1040, bad file extent, some csum missing >>>>> root 5 inode 12211 errors 1040, bad file extent, some csum missing >>>>> root 5 inode 15368 errors 1040, bad file extent, some csum missing >>>>> root 5 inode 35329 errors 1040, bad file extent, some csum missing >>>>> root 5 inode 960427 errors 1040, bad file extent, some csum missing >>>>> root 5 inode 18446744073709551605 errors 2001, no inode item, link count wrong >>>>> unresolved ref dir 256 index 0 namelen 12 name $RECYCLE.BIN filetype 2 errors 6, no dir index, no inode ref >>> >>> Check is reporting the same problem of the inode. >>> >>> We need to make sure what's going wrong on that leaf, based on the >>> mentioned dump. >>> >>> For the csum missing error and bad file extent, it should be a big problem. >> >> s/should/should not/ >> >>> if you want to make sure what's going wrong, please provide the >>> following dump: >>> >>> # btrfs ins dump-tree -t 5 /dev/sdb2 | grep -A 7 >>> >>> Also feel free the censor the filenames. >>> >>> Thanks, >>> Qu >>> >>>>> root 388 inode 1245 errors 1040, bad file extent, some csum missing >>>>> root 388 inode 1288 errors 1040, bad file extent, some csum missing >>>>> root 388 inode 1292 errors 1040, bad file extent, some csum missing >>>>> root 388 inode 1313 errors 1040, bad file extent, some csum missing >>>>> root 388 inode 11870 errors 1040, bad file extent, some csum missing >>>>> root 388 inode 68126 errors 1040, bad file extent, some csum missing >>>>> root 388 inode 88051 errors 1040, bad file extent, some csum missing >>>>> root 388 inode 88255 errors 1040, bad file extent, some csum missing >>>>> root 388 inode 88455 errors 1040, bad file extent, some csum missing >>>>> root 388 inode 88588 errors 1040, bad file extent, some csum missing >>>>> root 388 inode 88784 errors 1040, bad file extent, some csum missing >>>>> root 388 inode 88916 errors 1040, bad file extent, some csum missing >>>>> ERROR: errors found in fs roots >>>>> found 37167415296 bytes used, error(s) found >>>>> total csum bytes: 33793568 >>>>> total tree bytes: 1676722176 >>>>> total fs tree bytes: 1540243456 >>>>> total extent tree bytes: 81510400 >>>>> btree space waste bytes: 306327457 >>>>> file data blocks allocated: 42200928256 >>>>> referenced 52868354048 >>>> >>>> >>>> >>>> >>>> --- >>>> >>>> Regards, >>>> José Luis. >>>> >>> >>
Attachment:
signature.asc
Description: OpenPGP digital signature
