[dezgeg]

I wish checksumming filesystems had some interface to expose the internal checksums. Maybe it wouldn't be useful for rsync though as filesystems should have the freedom to pick the best algorithm (so filesystem checksum of a file on different machines would be allowed to differ e.g. if filesystem block size was different). But so that e.g. git and build systems could use it to tell 'these 2 files under a same directory tree are definitely identical'.

[mustache_kimono]

I actually once suggested this to ZFS, and saw some push back! See: https://github.com/issues/created?issue=openzfs%7Czfs%7C1453...

Maybe someone else will have better luck than me.

[jauntywundrkind]

That could also be useful for webserver etags too. Neat that the information is available! Just to admins only.

TIL that btrfs's checksums are per block, not per file. There's a dump-csum command, but doesn't seem likely to be very useful. https://unix.stackexchange.com/questions/191754/how-do-i-vie...

[heinrich5991]

Working link: https://github.com/openzfs/zfs/issues/14536.

[rob_c]

Sorry to break it to you. That's not about luck. You've asked for something which is nonsense if you want to "recycle" compute used to checksum records.

If you want them to store the checksum of the POSIX object as an attribute (we can argue about performance later) great, but using the checksums intrinsic to the zfs technology to avoid bitflips directly is a bad call.

[hello_computer]

If they expose it, that ties them to a particular hash algo. Hash algos are as much art as science, and the opportunities for hardware acceleration vary from chip to chip, so maintaining the leeway to move from one algo to another is kind of important.