On Feb 5, 2010, at 10:50 PM, grarpamp wrote: >>> 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, > > Well, ok, and in my limited knowhow... zfs set checksum=sha256 only > covers user scribbled data [POSIX file metadata, file contents, directory > structure, ZVOL blocks] and not necessarily any zfs filesystem internals.
metadata is fletcher4 except for the uberblocks which are self-checksummed using sha256. >> You can set the data to be checksummed with SHA256. > > Definitely, as indeed set above :) SHA256 is approximately 1/2 the speed of fletcher4, so the trade-off does not consider only the checksum algorithm. For older machines, the speed difference could be worse. >>> 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. > > The case had to have been previously made to include fletcher4 in the > zfs send/recv protocol. So sha256 would just be an update to the user's > options. Similar to how f4 was an available on disk update to f2, z3 to z2 > to z1, etc. This is a very different use case than the data stored on media. Since the pipe interface is very reliable, you can reasonably choose to use more or less protection through the pipe without complicating the ZFS user interface [insert UNIX philosophy argument here :-)] > Was really only looking to see what, if anything, was currently used in > the protocol, not actually proposing an update. Now I know :) > > Transport is certainly always up to the user: pipe/netcat/ssh/rsh/pigeon > >>> In any case, at least something is used over the bare wire :) >> UNIX pipes are a great invention! :-) > > Yeah, I suppose a pipe to ssh has enough bits to catch things these days. > Netcat might be different, ergo, at least f4 as already implemented. > > debug1: kex: server->client aes128-ctr hmac-sha1 none > debug1: kex: client->server aes128-ctr hmac-sha1 none I'm interested in anecdotal evidence which suggests there is a problem as it is currently designed. Thus far, I believe the reports of send stream corruption on this forum have been attributed to other things. -- richard _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
