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. There are many places where data can get corrupt even when you are using ZFS. Non ECC memory is one example. There might be a bug in zfs but that is hard to check as you can't reproduce the problem. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
