3

Git produces a commit ID by hashing various components in such a way that we essentially get an identifier for the entire history of the project.

From my understanding ZFS hashes everything (data / metadata / filesystem structure), which presumably results in a single "top-level" hash at the root of the filesystem.

I was wondering if there was a way to get at such a hash or identifier from a ZFS filesystem or snapshot.

This could potentially be used to quickly and reliably confirm with decent confidence that "all the data in dataset-x matches all the data in dataset-y".

I don't have full understanding of the internals of zfs send and zfs recv, but I would presume that they deal with such concepts, ensuring that both the sending and receiving filesystems have a common starting point.


Edit: I have off-site backups which are automated using syncoid... If I were to look at the matching snapshot on each of the corresponding filesystems across the n-pools, I'd expect to see the same identifier.

It could also potentially be useful to see if there are any changes between snapshots of a dataset, though I suspect that the snapshot attributes (name, date, etc...) might affect this identifier, so it would be good to look "one level down" for this one.

3

As I understand it, all references to other blocks in ZFS contain the checksum that other block should have, and those blocks in turn contain pointers with checksums (eventually pointing to data blocks and their checksums). At the root of all this, you have the uberblock's checksum which then implicitly covers all data in the pool.

But that checksum includes the actual block pointers and things that are related to the physical file system layout, so you couldn't really use it to verify just the data - if you e.g. zfs send/recv the file systems you'll end up with a completely different checksum.

  • A very good point, thanks very much! I suspect you're correct re including pointers and other things that will make the same data have a different checksum. – Attie Jan 22 '18 at 10:04
0

You may want to look into zfs diff for this case.

Can you elaborate on the use case. Will these be filesystems in the same data pool?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.