NFSv4 - how to set up at FreeBSD 8.1 ?

[John Baldwin]

On Thursday, January 06, 2011 3:08:04 am perryh at pluto.rain.com wrote:
> John Baldwin <jhb at 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