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. 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 Is there any magic command to repair my sdb2 filesystem? Or I have to backup data and rebuild those filesystems? Thanks Qu, José Luis El mar., 15 oct. 2019 a las 15:25, Qu Wenruo (<quwenruo.btrfs@xxxxxxx>) escribió: > > > > 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. > >>>> > >>> > >> >
