Date: Mon, 30 Mar 2009 22:01:36 -0700 From: perryh@pluto.rain.com To: zbeeble@gmail.com Cc: freebsd-stable@freebsd.org Subject: Re: ZFS and NFS: changing handles between reboots Message-ID: <49d1a3b0.vaFwcG1IJaRQg%2BMR%perryh@pluto.rain.com> In-Reply-To: <5f67a8c40903301038i31e18598ld17c645548b6feda@mail.gmail.com> References: <alpine.BSF.2.00.0903300035550.30609@woozle.rinet.ru> <E1LoFor-000D9h-5k@dilbert.ticketswitch.com> <5f67a8c40903301038i31e18598ld17c645548b6feda@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Zaphod Beeblebrox <gmail.com!zbeeble@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49d1a3b0.vaFwcG1IJaRQg%2BMR%perryh>