Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 06 Jan 2011 00:08:04 -0800
From:      perryh@pluto.rain.com
To:        jhb@freebsd.org
Cc:        marek_sal@wp.pl, freebsd-stable@freebsd.org, jyavenard@gmail.com, rmacklem@uoguelph.ca, milu@dat.pl
Subject:   Re: NFSv4 - how to set up at FreeBSD 8.1 ?
Message-ID:  <4d257864.YjgoS235V8eKvUX2%perryh@pluto.rain.com>
In-Reply-To: <201101050757.08116.jhb@freebsd.org>
References:  <1036681015.111502.1294189339355.JavaMail.root@erie.cs.uoguelph.ca> <4d244e39.KoPcOoMaWed%2BH5De%perryh@pluto.rain.com> <201101050757.08116.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin <jhb@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.)

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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4d257864.YjgoS235V8eKvUX2%perryh>