On Mon, Sep 28, 2015 at 07:11:51PM -0400, Calvin Walton wrote: > On Thu, 2015-09-24 at 21:48 +0300, Matwey V. Kornilov wrote: > > 2015-09-24 21:35 GMT+03:00 Austin S Hemmelgarn <ahferroin7@xxxxxxxxx> > > : > > > On 2015-09-24 14:06, Matwey V. Kornilov wrote: > > > > It's worth noting that the way btrfs does checksums isn't per-file, > > > it's > > > per-block. This means that: > [...] > > > All in all, this means that if you just want a checksum of the > > > contents of > > > the file, it's almost certainly better to just do it in userspace. > > > If you're trying to figure out what changed, using send/receive and > > > snapshots is more efficient (usually). > > > > I want the checksums of the every block of the file to see which part > > has been changed. > > I cannot use send/receive because my other file replica is on the > > remote host but not on the same filesystem. Compare with how rsync > > works. It calculates checksums of the chunks of both versions of the > > file and then syncs different chunks over the network. I just want to > > utilize the fact that btrfs already has the data I need to calculate. > > The problem with trying to use btrfs checksums to compare two different > files is that the blocks might not match up, if only due to > fragmentation. E.g., the same 1gb file might be stored like this on one > machine: > > [ 256MB ][ 512 MB ][ 256MB ] > > And like this on the other: > [ 512MB ][ 512MB ] > > Since the checksums are per block, and the blocks can be different > arrangements on different machines, they're not really all that useful > for doing comparisons like you want. No, those are extents, not blocks, and the FS doesn't checksum in extents. :) Blocks are 4 KiB in size. Hugo. -- Hugo Mills | SCSI is usually fixed by remembering that it needs hugo@... carfax.org.uk | three terminations: One at each end of the chain. http://carfax.org.uk/ | And the goat. PGP: E2AB1DE4 | Andrew McDonald, HantsLUG
Attachment:
signature.asc
Description: Digital signature
