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>