> Save the data to a file stored in zfs. Then you are > covered. :-)
Only if the stream was also separately covered in transit. While you want in-transit protection regardless, "zfs recv"ing the stream into a pool validates that it was not damaged in transit, as well as giving you at-rest protection thereafter. In the context of storage, end-to-end means writer-to-reader across a time gap. ZFS gives us this nicely, for regular files locally. For streams, it's send-to-recv; introducing a time gap with intermediate storage is fine, but you need to recognise that a stored stream is still "in transit" and has not yet been validated. This recognition helps you decide things like whether it's yet safe to rely on it as a backup (eg destroy the original copy in a migration). As an aside, there are other ways to validate integrity, if you want to store a stream as a file - you could gpg-sign the stream and verify the signature once on storage at the other end. That still leaves you with the version-skew exposures of stream storage. Those version-skew issues can be a hindrance regardless of time - even a piped stream between old and new systems can cause problems when trying to migrate and upgrade. The problem here is not so much how the system works; for better or worse, once that's understood people can design their solutions accordingly, perhaps with a bit of grumbling about reduced convenience. The immediate issue here is that various documentation and examples and guides provide mixed and even contradictory advice which hinders or hides that understanding. This can lead to surprises and anger, when a recommended solution relies on recovery from a saved stream that has not been validated. Userland tools to read and verify a stream, without having to play it into a pool (seek and io overhead) could really help here. -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
