On 2019/9/30 上午11:44, Andrey Ivanov wrote: > > During work I had experienced problems with access to files on the btfs > partition. > I rebooted the computer and after that the partition did not mount. > > # mount /dev/sdc1 /data > mount: /data: wrong fs type, bad option, bad superblock on /dev/sdc1, > missing codepage or helper program, or other error. > > > I think the logical structure of partition is corrupted. > Can it be restored somehow? > > > System info: > > # uname -a > Linux tux64 4.19.72-gentoo #1 SMP Sun Sep 15 12:27:44 MSK 2019 x86_64 > Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz GenuineIntel GNU/Linux > > # btrfs --version > btrfs-progs v4.19 > > # btrfs fi show > Label: none uuid: a942b8da-e92d-4348-8de9-ded1e5e095ad > Total devices 1 FS bytes used 101.56GiB > devid 1 size 465.01GiB used 105.01GiB path /dev/sda4 > > Label: none uuid: 62164480-0c5e-45da-807b-33f8bfe76ecf > Total devices 1 FS bytes used 1.36TiB > devid 1 size 2.70TiB used 1.38TiB path /dev/sdc1 > > > dmesg.log attached [[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 [[DETAILED REASON]] In btrfs, DIR_ITEM DIR_INDEX and XATTR_ITEM shares the same btrfs_dir_item structure. However DIR_ITEM and DIR_INDEX should only use namelen, only XATTR_ITEM uses data_len. Btrfs detects such anomaly and refuse to read the offending tree block, which leads to this mount failure. [[POSSIBLE CAUSE]] Normally it should be some older FS got mounted by older kernels, which sometimes didn't completely follow btrfs on-disk schema. [[EXTRA INFO]] Please provide the following dump of that tree block by: # btrfs ins dump-tree -b 134079905792 /dev/sda4 We need such info to further confirm the problem. Please note that this dump will contain filenames, feel free to filter sensitive filenames. [[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. Thanks, Qu
Attachment:
signature.asc
Description: OpenPGP digital signature
