Re: Broken chunk tree - Was: Mount issue, mount /dev/sdc2: can't read superblock

[Duncan <1i5t5.duncan@cox.net>]

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