ZFS and NFS: changing handles between reboots

[perryh at pluto.rain.com]

Zaphod Beeblebrox <gmail.com!zbeeble at agora.rdrop.com> wrote:
> ... reboots of an NFS server are meant to be transparent to the
> clients (save the downtime involved).

Not just downtime; how would you like to have to restart your whole
X11, OpenWindows, or SunTools session -- losing all current user-
oriented state and perhaps considerable work -- every time some
occasionally-used NFS server reboots?  Many of the design decisions
involved predate the common use, if not the very existence, of
automounters.

> Typically, stale NFS file handle indicates that the mount the
> client currently sees does not have the same hash as the mount
> it was using.
>
> Seeing this [stale handle after a simple server reboot] on ZFS
> would be a bug.  Seeing this on UFS would just be strange...

I'd count it a bug either place, at least if the mount is using UDP
transport.  NFS (over UDP) has handled server reboots transparently
to the clients at least as far back as SunOS 3.5.  (The design
decision to make NFS stateless on the server, which drove the use of
UDP for transport, is also a contributing factor in the complexity
-- and IMO the ultimate futility -- of lockd.)

OTOH, a TCP-connected client *will* get a "connection reset by peer"
when the server reboots; dunno what the NFS/TCP spec says about
reestablishing.