On Fri, Feb 15, 2019 at 2:31 PM Martin Pöhlmann <mpdeimos@xxxxxxxxx> 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): > > [ 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 This suggests a crash or power failure, as there's a log that needs to be replayed to mount the file system, but that log replay has failed. Try: mount -o ro,nologreplay <dev> <mp> If that works without additional errors, go ahead an unmount. If you're willing to take a small risk of the last, maybe minute or so of transactions being lost, and you need to get up and running sooner than later, you can zero the log. btrfs rescue zero-log <dev> However, it might be useful to try and provide more information first because log replay should not fail. btrfs insp dump-s -f <dev> >From that you will see an item log_root and a number after it. Copy that number and paste it in here: btrfs insp dump-t -b <logtreeaddr> --follow <dev> I'm not sure how much information btrfs dump tree can provide about log trees, but worth a shot I guess. > 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 > > # 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 Hmm, that's possibly getting tripped up on the log. I'm not sure. So I'm still curious if it can mount ro without log replay. That's a safe command, it doesn't make any changes on disk. If it works, you can back up some files while you have the chance in case repair attempts don't work or things get worse. Obviously the less you change the system (zero log, and check --repair both write to the file system and change it) the better off you are until a developer can give advice. But it's also Friday and it might be a few days before one gets to reply. So, if you can wait, do that. -- Chris Murphy
