Mattias Pantzare wrote: > 2008/8/13 Jonathan Wheeler <[EMAIL PROTECTED]>: >> So far we've established that in this case: >> *Version mismatches aren't causing the problem. >> *Receiving across the network isn't the issue (because I have the exact same >> issue restoring the stream directly on >> my file server). >> *All that's left was the initial send, and since zfs guarantees end to end >> data integrity, it should have been able to deal >> with any network possible randomness in the middle (zfs on both ends) - or >> at absolute worst, the zfs send command >> should have failed, if it encountered errors. Seems fair, no? >> >> So, is there a major bug here, or at least an oversight in the zfs send part >> of the code? >> Does zfs send not do checksumming, or, verification after sending? I'm not >> sure how else to interpret this data. > > zfs send can't do any verification after sending. It is sending to a > pipe, it does not know that it is writing to a file. ZFS receive can > verify the data, as you know. > > ZFS is not involved in moving the data over the network when you are using > NFS.
ZFS is never involved in moving data over the network. It doesn't know anything about networking. Even if you are using iSCSI or FCoE ZFS still doesn't know about networking the "disk" layers do. For the ZFS send/recv cases as you said it just writes to stdout and reads from stdin. -- Darren J Moffat _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
