Darren J Moffat wrote: > Moore, Joe wrote: > > Given the fact that NFS, as implemented in his client > systems, provides no end-to-end reliability, the only data > protection that ZFS has any control over is after the write() > is issued by the NFS server process. > > NFS can provided on the wire protection if you enable Kerberos support > (there are usually 3 options for Kerberos: krb5 (or sometimes called > krb5a) which is Auth only, krb5i which is Auth plus integrity provided > by the RPCSEC_GSS layer, krb5p Auth+Integrity+Encrypted data. > > I have personally seen krb5i NFS mounts catch problems when > there was a > router causing failures that the TCP checksum don't catch.
No doubt, additional layers of data protection are available. I don't know the state of RPCSEC on Linux, so I can't comment on this, certainly your experience brings valuable insight into this discussion. It is also recommended (when iSCSI is an appropriate transport) to run over IPSEC in ESP mode to also ensure data-packet-content consistancy. Certainly NFS over IPSEC/ESP would be more resistant to on-the-wire corruption. Either of these would give better data reliability than pure NFS, just like ZFS on the backend gives better data reliability than for example, UFS or EXT3. --Joe _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
