On Fri, March 19, 2010 09:49, Bob Friesenhahn wrote: > On Fri, 19 Mar 2010, David Dyer-Bennet wrote: >> >> However, these legacy mechanisms aren't guaranteed to give you the >> less-than-one-wrong-bit-in-10^15 level of accuracy people tend to want >> for >> enterprise backups today (or am I off a couple of orders of magnitude >> there?). They were defined when data rates were much slower and data >> volumes much lower. > > Are you sure? Have you done any research on this? You are saying > that NSA+-grade crypto on the stream is insufficient to detect a > modification to the data?
I was referring to the tcp and hardware-level checksums. I specifically said I didn't know if SSH did anything on top of that (other people have since said that it does, and it might well be plenty good enough; also that ZFS itself has checksums in the send stream). I don't think of stream crypto as inherently including validity checking, though in practice I suppose it would always be a good idea. > It seems that the main failure mode would be disconnect by ssh. Sure, can't guarantee against aborted connections at whatever level (actual interruption of IP connectivity). But those are generally detected and reported as an error; one shouldn't be left with the impression the transfer succeeded. -- David Dyer-Bennet, d...@dd-b.net; http://dd-b.net/ Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ Photos: http://dd-b.net/photography/gallery/ Dragaera: http://dragaera.info _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
