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>
index | next in thread | previous in thread | raw e-mail
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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4d257864.YjgoS235V8eKvUX2%perryh>