All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Niccolò Belli" <darkbasic@linuxsystems.it>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Unmountable / uncheckable Fedora 34 btrfs: failed to read block  groups: -5 open_ctree failed
Date: Sun, 12 Sep 2021 17:51:25 +0200	[thread overview]
Message-ID: <7294d85b7a0b3386be95fbe2d1ec6f9b@linuxsystems.it> (raw)
In-Reply-To: <e71b92f4-43ba-1544-07c7-2dcc1dbf546c@gmx.com>

Il 2021-09-12 15:35 Qu Wenruo ha scritto:
> My bad, the commit is 2b29726c473b ("btrfs: rescue: allow ibadroots to
> skip bad extent tree when reading block group items"), which is only
> merged into the incoming v5.15-rc1.

I've compiled linux-git master and tried again:

$ uname -a
Linux arch-laptop 5.14.0-1-git-11152-g78e709522d2c #1 SMP PREEMPT Sun, 
12 Sep 2021 12:53:13 +0000 x86_64 GNU/Linux

$ sudo mount -o ro,rescue=ibadroots 
/run/media/niko/3ea0705c-21c9-4ba9-80ee-5a511cb2a093/nvme0n1p6.img.copy 
/mnt2/
mount: /mnt2: can't read superblock on /dev/loop0.

[  196.277414] loop: module loaded
[  196.278228] loop0: detected capacity change from 0 to 207618048
[  196.736456] BTRFS: device label fedora_localhost-live devid 1 transid 
1029644 /dev/loop0 scanned by mount (2730)
[  196.736819] BTRFS info (device loop0): flagging fs with big metadata 
feature
[  196.736825] BTRFS info (device loop0): ignoring bad roots
[  196.736826] BTRFS info (device loop0): disk space caching is enabled
[  196.736827] BTRFS info (device loop0): has skinny extents
[  197.408704] BTRFS warning (device loop0): checksum verify failed on 
21348679680 wanted 0xd05bf9be found 0x2874489b level 1
[  197.408843] BTRFS info (device loop0): start tree-log replay
[  197.408847] BTRFS warning (device loop0): log replay required on RO 
media
[  197.409458] BTRFS error (device loop0): open_ctree failed

So I've added nologreplay and it did the trick:

$ sudo mount -o ro,rescue=nologreplay:ibadroots 
/run/media/niko/3ea0705c-21c9-4ba9-80ee-5a511cb2a093/nvme0n1p6.img.copy 
/mnt2/

[  416.913016] loop0: detected capacity change from 0 to 207618048
[  416.918895] BTRFS info (device loop0): flagging fs with big metadata 
feature
[  416.918903] BTRFS info (device loop0): disabling log replay at mount 
time
[  416.918905] BTRFS info (device loop0): ignoring bad roots
[  416.918907] BTRFS info (device loop0): disk space caching is enabled
[  416.918908] BTRFS info (device loop0): has skinny extents
[  416.929887] BTRFS warning (device loop0): checksum verify failed on 
21348679680 wanted 0xd05bf9be found 0x2874489b level 1

$ sudo btrfs subvolume list /mnt2 | grep -v snapshot | grep -v docker
ID 256 gen 1029644 top level 5 path home
ID 265 gen 1029641 top level 256 path home/niko/.cache
ID 912 gen 1029406 top level 5 path images
ID 2428 gen 359129 top level 5 path var
ID 2429 gen 1026054 top level 2428 path var/tmp
ID 2430 gen 1029044 top level 2428 path var/cache
ID 2433 gen 1029641 top level 5 path root
ID 2653 gen 1029641 top level 5 path avd

$ ls -al /mnt2
totale 16
drwxr-xr-x 1 root root  58 16 giu 19.09 .
drwxr-xr-x 1 root root 198 12 set 17.50 ..
drwxr-xr-x 1 niko niko  72 26 ago 10.22 avd
drwxr-xr-x 1 root root  28 16 apr 10.25 home
drwxrwxrwx 1 niko niko  96 20 ago 17.23 images
dr-xr-xr-x 1 root root 196 24 ago 14.58 root
drwxr-xr-x 1 root root  28 16 apr 10.21 snapshots
drwxr-xr-x 1 root root  16 13 giu 00.10 var

Apart from backing my files up, what else should I be able to do at this 
point?

I've tried scrubbing but it's a no go:

$ sudo btrfs scrub start /dev/loop0
scrub started on /dev/loop0, fsid d3d387d6-eb5e-4b4b-9a9c-581d74fb56b4 
(pid=3255)

$ sudo btrfs scrub status /dev/loop0
UUID:             d3d387d6-eb5e-4b4b-9a9c-581d74fb56b4
Scrub started:    Sun Sep 12 18:00:30 2021
Status:           aborted
Duration:         0:00:00
Total to scrub:   97.27GiB
Rate:             0.00B/s
Error summary:    no errors found

Any chance to recover the partition?

Niccolò

  reply	other threads:[~2021-09-12 16:07 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-12 10:27 Unmountable / uncheckable Fedora 34 btrfs: failed to read block groups: -5 open_ctree failed Niccolò Belli
2021-09-12 10:44 ` Niccolò Belli
2021-09-12 10:46   ` Niccolò Belli
2021-09-12 11:14 ` Qu Wenruo
2021-09-12 11:41   ` Niccolò Belli
2021-09-12 13:35     ` Qu Wenruo
2021-09-12 15:51       ` Niccolò Belli [this message]
2021-09-13 14:50         ` Zygo Blaxell
2021-09-13 20:40           ` Niccolò Belli
2021-09-12 21:23   ` Niccolò Belli
2021-09-12 23:55     ` Qu Wenruo
2021-09-13  7:16       ` Niccolò Belli
2021-09-13  8:05         ` Qu Wenruo
2021-09-13 11:58           ` Niccolò Belli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7294d85b7a0b3386be95fbe2d1ec6f9b@linuxsystems.it \
    --to=darkbasic@linuxsystems.it \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.