> John Baldwin <j...@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.) > 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 _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
