On 2019/2/16 上午5:31, Martin Pöhlmann wrote: > Hello, > > After a reboot I am lost with an unmountable BTRFS partition. Before > reboot I had first compile problems with freezing IntelliJ. These > persisted after a first reboot, after a second reboot I am faced with > the following error after entering the dm-crypt password (also after > manual mount with -o ro,recovery, see attached dmesg): [Move check result here] > # btrfs check --readonly /dev/mapper/cryptroot > [1/7] checking root items > [2/7] checking extents > [3/7] checking free space cache > [4/7] checking fs roots > root 258 inode 776 errors 200, dir isize wrong > root 258 inode 1131031 errors 1, no inode item > unresolved ref dir 776 index 87215 namelen 17 name > TransportSecurity filetype 1 errors 5, no dir item, no inode ref > root 258 inode 2911226 errors 1, no inode item > unresolved ref dir 776 index 160611 namelen 17 name > TransportSecurity filetype 1 errors 5, no dir item, no inode ref > ERROR: errors found in fs roots > Opening filesystem to check... > Checking filesystem on /dev/mapper/cryptroot > UUID: bbd941a4-5525-4ba6-a4d8-3ead02b8aae1 > found 409699909636 bytes used, error(s) found > total csum bytes: 390595732 > total tree bytes: 5061541888 > total fs tree bytes: 4224024576 > total extent tree bytes: 339312640 > btree space waste bytes: 892618468 > file data blocks allocated: 529336496128 > referenced 490479570944 > So there is just some minor problem in fs trees, not a big problem, and your extent tree passes the check, so it's not on-disk data corruption. > > [ 6098.921985] BTRFS error (device dm-0): unable to find ref byte nr > 390335463424 parent 0 root 2 > [ 6098.922473] BTRFS: error (device dm-0) in __btrfs_free_extent:6828: > errno=-2 No such entry > [ 6098.922526] BTRFS: error (device dm-0) in > btrfs_run_delayed_refs:2978: errno=-2 No such entry > [ 6098.922601] BTRFS: error (device dm-0) in btrfs_replay_log:2267: > errno=-2 No such entry (Failed to recover log tree) > [ 6098.972326] BTRFS error (device dm-0): open_ctree failed It's log recovery causing problem. You could just use "btrfs rescue zero-log" to recovery it. Thanks, Qu > > I've searched for a solution on the web, but most articles tell to do > nothing, but write to this mailing list. So my hopes are that you can > shed some light into what I can do. > > I've found a quite recent thread here > (https://lore.kernel.org/linux-btrfs/5b0d2e94-6e4e-aecd-3eda-459c4a96bb13@xxxxxxxxxxxxxx/) > but this just mentions a fix for 'Fix missing reference aborts when > resuming snapshot delete' and is not further specific. > > Setup of my SSD looks like: > > * efi > * dm-crypt plain. Contains BTRFS (w/o lvm or similar). Several > subvolumes (/, /home, ...) > * swap > > I've already run btrfs restore on volid 258 (home) and gathered lots > of data from the disk (>200GB). I also have a dd backup of the > cryptroot after the failure happened (in case something goes wrong). > Besides I did not do any fix attempts yet. If there is anything I can > do to get the system working again, I'm happy to hear. > > Thanks! > > My Linux system is Arch Linux (up to date), logs below come from the > Arch install medium . > > # uname -a > Linux archiso 4.20.6-arch1-1-ARCH #1 SMP PREEMPT Thu Jan 31 08:22:01 > UTC 2019 x86_64 GNU/Linux > > # btrfs --version > btrfs-progs v4.19.1 > > # btrfs fi show > Label: 'root' uuid: bbd941a4-5525-4ba6-a4d8-3ead02b8aae1 > Total devices 1 FS bytes used 381.56GiB > devid 1 size 460.39GiB used 393.01GiB path /dev/mapper/cryptroot >
Attachment:
signature.asc
Description: OpenPGP digital signature
