Re: Force recalculation of a data block checksum

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

Tomasz Melcer posted on Sun, 24 Jul 2016 04:03:08 +0200 as excerpted:

> How can I ask btrfs to recompute the checksum of a data block as it is
> stored on the drive? I don't see any command doing an operation like
> that, and I couldn't find anything on the topic on the internet.

There's no "easy" btrfs method to recompute the checksum of an individual 
block (you'd have to do some deep debugging and hex editing to manually 
rewrite the correct sum), but there /is/ one that reinitiates and 
recalculates checksums for the entire filesystem.

You don't mention what version of btrfs-progs you have, but you'll want a 
reasonably new one, as AFAIK the command is fairly new, and early 
versions of the command simply wiped the existing checksums without 
recalculating them.

btrfs check --init-csum-tree

... as found in the btrfs-check manpage.


Another alternative is using btrfs restore, again, see the btrfs-restore 
manpage.  Normally this command is used to get what you can off of a 
filesystem damaged badly enough it won't mount, but you can also use it 
to scrape specific files off an unmounted filesystem, if the checksum's 
bad, for instance.  In this case, you'd use the --path-regex option to 
restore only files matching that regex.  Of course, for a TB-sized file, 
you'll need a separate filesystem (need not be btrfs, but will need to be 
a filesystem that can handle a file that size) with at least a TB free to 
write it to.

I'd normally prefer the btrfs restore method, myself, particularly if the 
btrfs in question has other files that you don't want to risk in the 
process.  If that was the only file on the filesystem, I'd still try the 
restore method first, at least if I had some place to write it to, 
because btrfs restore is read-only against the btrfs you're restoring 
from, and thus has no chance of causing further damage, while of course 
btrfs check --init-csum-tree writes to the filesystem in question and 
thus is a higher risk.

-- 
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