On Feb 5, 2010, at 8:09 PM, grarpamp wrote: >>> 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. > >>> Was thinking that plaintext ethernet/wan and even some of the 'weaker' >>> ssl algorithms > >> Do you expect the same errors in the pipe as you do on disk? > > Perhaps I meant to say that the box itself [cpu/ram/bus/nic/io, except disk] > is assumed to handle data with integrity. So say netcat is used as transport, > zfs is using sha256 on disk, but only fletcher4 over the wire with send/recv, > and your wire takes some undetected/uncorrected hits, and the hits also > happen to make it past fletcher4... it kindof nullifies the SA's > choice/thought > that sha256 would be used throughout all zfs operations.
Hold it right there, fella. SHA256 is not used for everything ZFS, so expecting it to be so will set the stage for disappointment. You can set the data to be checksummed with SHA256. > I din't see notation in the man page that checksums are indeed used > in send/recv operations... It is an implementation detail. But if you can make the case for why it is required to be inside the protocol, rather than its transport, then please file an RFE. > In any case, at least something is used over the bare wire :) Lots of things are used on the bare wire and there are many hops along the way. This is another good reason to use ssh, or some other end-to-end verification mechanism. UNIX pipes are a great invention! :-) -- richard _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
