NFSv4 - how to set up at FreeBSD 8.1 ?

Rick Macklem rmacklem at
Thu Jan 6 13:18:12 UTC 2011

> John Baldwin <jhb at> 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.)
For UDP, in the server all requests show up at socket/port 2049. They
pretty quickly discovered that retries of non-idempotent RPCs trashed
things, so the Duplicate Request Cache was invented, which is really
state that doesn't have to be recovered after a server crash.
(By Chet Jacuzak at DEC, if I recall correctly, who is living on a
little island on a lake up in Maine, last I heard.)

My recollection of why Sun didn't use TCP was that "they knew that
the overhead would be excessive", which wasn't completely untrue,
given the speed of an MC68020.

> 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.
Yea, it depended on how the backup was done. To avoid "stale handle"
the backup/reload had to retain the same i-nodes, including the generation
number in them. (But, then, those 1980s SMD disks never trashed the
file systems, or did they?:-)

You shouldn't get me reminising on the good ole days, rick

More information about the freebsd-stable mailing list