On Feb 5, 2010, at 7:20 PM, grarpamp wrote: >> 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.
Do you expect the same errors in the pipe as you do 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. most folks use ssh. -- richard _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss