> No. Checksums are made on the records, and there could be a different > record size for the sending and receiving file systems.
Oh. So there's a zfs read to ram somewhere, which checks the sums on disk. And then entirely new stream checksums are made while sending it all off to the pipe. I see the bit about different zfs block sizes perhaps preventing use of the actual on disk checksums in the transfer itself... including thereby, the chain to uberblock in the transfer. Thanks for that part. > The stream itself is checksummed with fletcher4. > I suppose one could say a calculated transfer fletcher4 checksum value. Hmm, is that configurable? Say to match the checksums being used on the filesystem itself... ie: sha256? It would seem odd to send with less bits than what is used on disk. >> The idea is to carry through the integrity checks wherever possible. >> Whether done as close as within the same zpool, or miles away. > yes. Was thinking that plaintext ethernet/wan and even some of the 'weaker' ssl algorithms would be candidates to back with sha256 in a transfer. Not really needed for a 'within the box only' unix pipe though. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
