linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Dawson <matthew@mjdsystems.ca>
To: linux-btrfs@vger.kernel.org
Subject: Help recovering filesystem (if possible)
Date: Sun, 14 Nov 2021 20:52:32 -0500	[thread overview]
Message-ID: <2586108.vuYhMxLoTh@cwmtaff> (raw)

Hi all,

I recently upgrade one of my machines to the 5.15.2 kernel.  on the first 
reboot, I had a kernel fault during the initialization (I didn't get to 
capture the printed stack trace, but I'm 99% sure it did not have BTRFS 
related calls).  I then rebooted the machine back to a 5.14 kernel, but the 
BCache (writeback) cache was corrupted.  I then force started the underlying 
disks, but now my BTRFS filesystem will no longer mount.  I realize there may 
be missing/corrupted data, but I would like to ideally get any data I can off 
the disks.

This system involves 10 8TB disk, some are doing BCache -> LUKS -> BTRFS, some 
are doing LUKS -> BTRFS.

When I try to mount the filesystem, I get the following in dmesg:
[117632.798339] BTRFS info (device dm-0): flagging fs with big metadata feature
[117632.798344] BTRFS info (device dm-0): disk space caching is enabled
[117632.798346] BTRFS info (device dm-0): has skinny extents
[117632.873186] BTRFS error (device dm-0): parent transid verify failed on 
132806584614912 wanted 3240123 found 3240119
[117632.873542] BTRFS error (device dm-0): parent transid verify failed on 
132806584614912 wanted 3240123 found 3240119
[117632.873592] BTRFS warning (device dm-0): couldn't read tree root
[117632.883662] BTRFS error (device dm-0): open_ctree failed

I then tried using rescue=all,ro to mount the filesystem, but got:
[117658.264048] BTRFS info (device dm-0): flagging fs with big metadata feature
[117658.264056] BTRFS info (device dm-0): enabling all of the rescue options
[117658.264057] BTRFS info (device dm-0): ignoring data csums
[117658.264059] BTRFS info (device dm-0): ignoring bad roots
[117658.264060] BTRFS info (device dm-0): disabling log replay at mount time
[117658.264061] BTRFS info (device dm-0): disk space caching is enabled
[117658.264062] BTRFS info (device dm-0): has skinny extents
[117658.286252] BTRFS error (device dm-0): parent transid verify failed on 
132806584614912 wanted 3240123 found 3240119
[117658.286573] BTRFS error (device dm-0): parent transid verify failed on 
132806584614912 wanted 3240123 found 3240119
[117658.286614] BTRFS warning (device dm-0): couldn't read tree root
[117658.294632] BTRFS error (device dm-0): open_ctree failed

Running btrfs check (not repair) to see if it had anything else printed:
parent transid verify failed on 132806546751488 wanted 3240122 found 3239869
parent transid verify failed on 132806546751488 wanted 3240122 found 3239869
parent transid verify failed on 132806571458560 wanted 3240122 found 3239869
parent transid verify failed on 132806571458560 wanted 3240122 found 3239869
parent transid verify failed on 132806571458560 wanted 3240122 found 3239869
parent transid verify failed on 132806571458560 wanted 3240122 found 3239869
Ignoring transid failure
leaf parent key incorrect 132806571458560
Couldn't setup extent tree
ERROR: cannot open file system

Running btrfs restore to see if data could be recovered prints:
parent transid verify failed on 132806584614912 wanted 3240123 found 3240119
parent transid verify failed on 132806584614912 wanted 3240123 found 3240119
parent transid verify failed on 132806584614912 wanted 3240123 found 3240119
parent transid verify failed on 132806584614912 wanted 3240123 found 3240119
Ignoring transid failure
Couldn't setup extent tree
Couldn't setup device tree
Could not open root, trying backup super
warning, device 6 is missing
warning, device 13 is missing
warning, device 12 is missing
warning, device 11 is missing
warning, device 7 is missing
warning, device 9 is missing
warning, device 14 is missing
bytenr mismatch, want=136920576753664, have=0
ERROR: cannot read chunk root
Could not open root, trying backup super
warning, device 6 is missing
warning, device 13 is missing
warning, device 12 is missing
warning, device 11 is missing
warning, device 7 is missing
warning, device 9 is missing
warning, device 14 is missing
bytenr mismatch, want=136920576753664, have=0
ERROR: cannot read chunk root
Could not open root, trying backup super

(All disks are present in the system)

Is there any hope in recovering this data?  Or should I give up on it at this 
point and reformat?  Most of the data is backed up (or are backups 
themselves), but I'd like to get what I can.

Thanks,
-- 
Matthew



             reply	other threads:[~2021-11-15  2:03 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-15  1:52 Matthew Dawson [this message]
2021-11-15 10:46 ` Help recovering filesystem (if possible) Kai Krakow
2021-11-18  2:57   ` Matthew Dawson
2021-11-18 21:09     ` Zygo Blaxell
2021-11-19  4:42       ` Matthew Dawson
2021-11-24  4:43         ` Zygo Blaxell
2021-11-24  5:11           ` Matthew Dawson
  -- strict thread matches above, loose matches on Subject: below --
2021-11-15  1:23 Matthew Dawson

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=2586108.vuYhMxLoTh@cwmtaff \
    --to=matthew@mjdsystems.ca \
    --cc=linux-btrfs@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).