On Thursday, January 06, 2011 3:08:04 am per...@pluto.rain.com wrote: > John Baldwin <j...@freebsd.org> wrote: > > > ... even NFS UDP mounts maintain their own set of "socket" state > > to manage retries and retransmits for UDP RPCs. > > Not according to what I remember of the SunOS NFS documentation, > which indicated that the driving force behind using UDP instead of > TCP was to have the server be _completely_ stateless. (Of course > locking is inherently stateful; they made it very clear that the > locking protocol was considered to be an adjunct rather than part > of the NFS protocol itself.)
No extra NFS state is tied to a TCP mount aside from maintaining TCP state (i.e. congestion window for the socket, etc.). A TCP mount does not have a different amount of NFS state than a UDP mount. As Rick noted, many servers do maintain a DRPC, but that applies to both UDP and TCP mounts. > It's been quite a few years since I read that, and I didn't get > into the details, but I suppose the handle returned to a client (in > response to a mount or open request) must have contained both a > representation of the inode number and a unique identification of > the filesystem (so that, in the case where server crash recovery > included a newfs and reload from backup, the FS ID would not match > and the client would get a "stale handle" response). All of the > retry and retransmit burden had to have been managed by the client, > for both reading and writing. Yes, this is true for both UDP and TCP (if you exclude TCP's retransmit for missed packets in server replies on a TCP mount). Even with TCP a client can still retransmit requests for which it does not receive a reply in case the connection dies due to a network problem, server reboot, etc. -- John Baldwin _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
