5
1
Btrfs offers these commands to verify data integrity/checksums:
btrfs scrub start <path>|<device>
btrfs check --check-data-csum
However, AFAIK those always verify whole filesystems; the path
argument is to identify a filesystem on a device, not file/directory within filesystem.
Now, I have a 3TB Btrfs filesystem. Scrubbing it takes hours. Sometimes I need to make sure that only certain file/directory has not yet been affected by bitrot — for example, before using an *.iso installation image or restoring a backup. How do I use Btrfs for this — without falling back to keeping manual hash files per each file?
I am aware that Btrfs does not store checksums for individual files — it stores checksums for blocks of data. In this case what I am looking for is a command/tool that identifies all the blocks used for storing certain files/directories and verifies those blocks only.
I read somewhere that Btrfs allegedly verifies checksums on read. That is, if a file has been bit-rotted, reading it would fail or something like that. Is this the case?
Do you regularly have a problem with files becoming corrupted? That's not normal, I'd suspect a bad drive or ram first, maybe bad filesystem drivers second. Instead of keeping hashes or checksums in a separate database to verify files, you could keep files in an archive that stores a checksum itself, and would save some space too. – Xen2050 – 2018-01-13T07:57:03.897
@Xen2050 no, no problems so far, just want to be able to get 100% confidence. Archives with built-in checksums are an option, but I'd like to employ Btrfs. – Greendrake – 2018-01-13T08:43:27.083