From: Chris Murphy <lists@colorremedies.com>
To: Sebastian Roller <sebastian.roller@gmail.com>
Cc: Chris Murphy <lists@colorremedies.com>,
Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: All files are damaged after btrfs restore
Date: Tue, 9 Mar 2021 13:34:15 -0700 [thread overview]
Message-ID: <CAJCQCtSDsVgrMnunviuAbgC_QFfOTDKdyRD1S=-5-Fbnv3EzBA@mail.gmail.com> (raw)
In-Reply-To: <CALS+qHPDYFU2mrzudR8w057Vo33NZ=YsRWJUYmAFUih1pWbz-w@mail.gmail.com>
On Tue, Mar 9, 2021 at 10:03 AM Sebastian Roller
<sebastian.roller@gmail.com> wrote:
> I found 12 of these 'tree roots' on the volume. All the snapshots are
> under the same tree root. This seems to be the subvolume where I put
> the snapshots.
Snapshots are subvolumes. All of them will appear in the root tree,
even if they're organized as being in a directory or in some other
subvolume.
>So for the snapshots there is only one option to use
> with btrfs restore -r.
It can be done by its own root node address using -f or by subvolid
using -r. The latter needs to be looked up in a reliable root tree.
But I think the distinction may not matter here because really it's
the chunk tree that's messed up, and that's what's used to find
everything. The addresses in the file tree (the subvolume/snapshot
tree that contains file listings, inodes, metadata, and the address of
the file) are all logical addresses in btrfs linear space. That means
nothing without the translation to physical device and blocks, which
is the job of the chunk tree.
>But I also found the data I'm looking for under
> some other of these tree roots. One of them is clearly the subvolume
> the backup went to (the source of the snapshots). But there is also a
> very old snapshot (4 years old) that has a tree root on its own. The
> files I restored from there are different -- regarding checksums.
> They are also corrupted, but different. I have to do some more
> hexdumps to figure out, if it's better.
Unfortunately when things are messed up badly, the recovery tools may
be looking at a wrong or partial checksum tree and it just spits out
checksum complaints as a matter of course. You'd have to inspect the
file contents themselves, the checksum warnings might be real or
bogus.
> > OK this is interesting. There's two chunk trees to choose from. So is
> > the restore problem because older roots point to the older chunk tree
> > which is already going stale, and just isn't assembling blocks
> > correctly anymore? Or is it because the new chunk tree is bad?
>
> Is there a way to choose the chunk tree I'm using for operations like
> btrfs restore?
Looks like the answer is no. The chunk tree really has to be correct
first before anything else because it's central to doing all the
logical to physical address translation. And if it's busted and can't
be repaired then nothing else is likely to work or be repairable. It's
that critical.
> I already ran chunk-recover. It needs two days to finish. But I used
> btrfs-tools version 4.14 and it failed.
I'd have to go dig in git history to even know if there's been
improvements in chunk recover since then. But I pretty much consider
any file system's tool obsolete within a year. I think it's total
nonsense that distributions are intentionally using old tools.
>
> root@hikitty:/mnt$ btrfs rescue chunk-recover /dev/sdf1
> Scanning: DONE in dev0
> checksum verify failed on 99593231630336 found E4E3BDB6 wanted 00000000
> checksum verify failed on 99593231630336 found E4E3BDB6 wanted 00000000
> checksum verify failed on 124762809384960 found E4E3BDB6 wanted 00000000
> checksum verify failed on 124762809384960 found E4E3BDB6 wanted 00000000
> checksum verify failed on 124762809384960 found E4E3BDB6 wanted 00000000
> checksum verify failed on 124762809384960 found E4E3BDB6 wanted 00000000
> bytenr mismatch, want=124762809384960, have=0
> open with broken chunk error
> Chunk tree recovery failed
>
> I could try again with a newer version. (?) Because with version 4.14
> also btrfs restore failed.
It is entirely possible that 5.11 fails exactly the same way because
it's just too badly damaged for the current state of the recovery
tools to deal with damage of this kind. But it's also possible it'll
work. It's a coin toss unless someone else a lot more familiar with
the restore code speaks up. But looking at just the summary change
log, it looks like no work has happened in chunk recover for a while.
https://btrfs.wiki.kernel.org/index.php/Changelog
> > btrfs insp dump-t -t 1 /dev/sdi1
> >
> > And you'll need to look for a snapshot name in there, find its bytenr,
> > and let's first see if just using that works. If it doesn't then maybe
> > combining it with the next most recent root tree will work.
>
> I am working backwards right now using btrfs restore -f in combination
> with -t. So far no success.
Yep. I think it comes down to the chunk tree needing to be reasonable
first, before anything else is possible.
--
Chris Murphy
next prev parent reply other threads:[~2021-03-09 20:35 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-23 15:45 All files are damaged after btrfs restore Sebastian Roller
2021-02-25 5:40 ` Chris Murphy
2021-02-25 5:52 ` Chris Murphy
2021-02-26 16:01 ` Sebastian Roller
2021-02-27 1:04 ` Chris Murphy
2021-03-04 15:34 ` Sebastian Roller
2021-03-05 3:01 ` Chris Murphy
2021-03-07 13:58 ` Sebastian Roller
2021-03-08 0:56 ` Chris Murphy
2021-03-09 17:02 ` Sebastian Roller
2021-03-09 20:34 ` Chris Murphy [this message]
2021-03-16 9:35 ` Sebastian Roller
2021-03-16 19:34 ` Chris Murphy
2021-03-17 1:38 ` Qu Wenruo
2021-03-17 2:59 ` Chris Murphy
2021-03-17 9:01 ` Sebastian Roller
2021-03-17 1:54 ` Dāvis Mosāns
2021-03-17 10:50 ` Sebastian Roller
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='CAJCQCtSDsVgrMnunviuAbgC_QFfOTDKdyRD1S=-5-Fbnv3EzBA@mail.gmail.com' \
--to=lists@colorremedies.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=sebastian.roller@gmail.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.