Tomáš Metelka posted on Sun, 30 Dec 2018 01:48:23 +0100 as excerpted:
> Ok, I've got it:-(
>
> But just a few questions: I've tried (with btrfs-progs v4.19.1) to
> recover files through btrfs restore -s -m -S -v -i ... and following
> events occurred:
>
> 1) Just 1 "hard" error:
> ERROR: cannot map block logical 117058830336 length 1073741824: -2 Error
> copying data for /mnt/...
> (file which absence really doesn't pain me:-))
>
> 2) For 24 files a I got "too much loops" warning (U mean this: "if
> (loops >= 0 && loops++ >= 1024) { ..."). I've always answered yes but
> I'm afraid these files are corrupted (at least 2 of them seems
> corrupted).
>
> How much bad is this? Does the error mentioned in #1 mean that it's the
> only file which is totally lost? I can live without those 24 + 1 files
> so if #1 and #2 would be the only errors then I could say the recovery
> was successful ... but I'm afraid things aren't such easy:-)
In this context, the biggest thing to know about btrfs restore is that
because it's meant as a recovery measure and if it comes to using
restore, the assumption is that the priority is recovery of /anything/
even if the checksums don't match (a chance of recovery of possibly bad
data is considered better than rejecting possibly bad data entirely), it
doesn't worry too much about checksums (AFAIK it ignores data checksums
entirely, not sure whether it checks metadata checksums or not, but it
probably ignores failure in at least some cases if it does, because
that's the point for a tool like this).
Which means that anything recovered using btrfs recover doesn't have the
usual btrfs checksums validation guarantees, and could very possibly be
corrupt.
However, that's mitigated by the fact that most filesystems don't even
have built-in checksumming and validation in the first place, so the data
on them could go bad even in normal operation, and unless it was
obviously corrupted into not working, you'd likely never even know it, so
btrfs restore ignoring checksums simply returns the data to the state
it's /normally/ in on most filesystems, completely unverified.
But if you happen to have checksums independently stored somewhere, or
even just ordinary unvalidated backups you can compare against, and
you're worried about the possibility of undiscovered corruption due to
the restore, and/or you were using btrfs in part /because/ of its built-
in checksum verification, it could be worth doing that verification run
against your old checksum database or backups.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
