From owner-freebsd-stable@FreeBSD.ORG Tue Mar 31 05:13:09 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE8C41065674 for ; Tue, 31 Mar 2009 05:13:09 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [199.26.172.34]) by mx1.freebsd.org (Postfix) with ESMTP id 86A068FC12 for ; Tue, 31 Mar 2009 05:13:09 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id n2V5D8bl026685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 30 Mar 2009 22:13:08 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id n2V5D8H6026684; Mon, 30 Mar 2009 22:13:08 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA05499; Mon, 30 Mar 09 21:03:10 PST Date: Mon, 30 Mar 2009 22:01:36 -0700 From: perryh@pluto.rain.com To: zbeeble@gmail.com Message-Id: <49d1a3b0.vaFwcG1IJaRQg+MR%perryh@pluto.rain.com> References: <5f67a8c40903301038i31e18598ld17c645548b6feda@mail.gmail.com> In-Reply-To: <5f67a8c40903301038i31e18598ld17c645548b6feda@mail.gmail.com> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ZFS and NFS: changing handles between reboots X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 05:13:10 -0000 Zaphod Beeblebrox 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.