I can't help but keep wondering if not some sort of FEC wrapper (optional of course) might solve both the "backup" and some of the long-distance-transfer (where retransmissions really isn't wanted) issues.
Reason I'm saying long-distance, is this is where latency-on-the-link starts rearing its ugly head, and where a pure udp stream is beneficial (since that doesn't depend on so many ack packages in return). Albeit with some earlier discussions using words like "brokenfletcher" to describe things (in a relatively heated discussion I wasn't part of, see the thread here: http://mail.opensolaris.org/pipermail/zfs-discuss/2009-October/032432.html), it seems the zfs code already contain rather good hashing-algorithms for error-detection. This is a good thing. Really it is. Especially if there is and option for adding something rather lightweight (when not correcting errors, that is) like CIRC (Cross-Interleaved Reed-Solomon Codes) wrapped around the send. Now, I'm not saying that we apply CIRC itself, since that has been destroyed for these purposes (some broken countries have software patents, and CIRC has been patented in that country, see US4413340), but the method itself (two layers of reed-solomon encoding) gives rather good options for not only error-detection but also correcting it. This would be beneficial for Sun^wOracle's enterprise customers as well. But I'm thinking that for snapshotting things like "this is what I need to get enough of the system up and running to run a full restore!" this should probably be applied to the much wanted "zpool send and receive" ideas. ;) (the reasoning being that "enough code to grab the rpool from backup" can be sent over PXE to the box needing restore) //Svein -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
