From owner-freebsd-current@FreeBSD.ORG Tue Aug 11 23:17:32 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90FCF1065672 for ; Tue, 11 Aug 2009 23:17:32 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 420318FC21 for ; Tue, 11 Aug 2009 23:17:31 +0000 (UTC) Received: from phobos.local (pooker.samsco.org [168.103.85.57]) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n7BMiJbL045342; Tue, 11 Aug 2009 16:44:20 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4A81F443.5030905@samsco.org> Date: Tue, 11 Aug 2009 16:44:19 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Rick Macklem References: <20090702121640.D245@maildrop.int.zabbadoz.net> <20090702122955.J245@maildrop.int.zabbadoz.net> <20090702212505.GA39889@stack.nl> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: "Bjoern A. Zeeb" , FreeBSD current mailing list , Jilles Tjoelker Subject: Re: Install from NFS onto NFS fails on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 23:17:32 -0000 Rick Macklem wrote: > > > On Thu, 2 Jul 2009, Jilles Tjoelker wrote: > >> >> This could be because of NFS "sillyrename". To avoid some ESTALE errors, >> the NFS client (for NFSv2 and NFSv3 at least) renames if you delete a >> file that is currently in use (in this case, the rm binary). Because the >> renamed file (name typically starts with .nfs) is in the same directory, >> this causes problems when removing directories. Once the file is no >> longer in use, it is finally deleted. >> > Yes, if some file that was in that directory is still open (or mmap'd and > the process hasn't yet exit()'d), it will exist as a file named ".nfsXXX" > until the v_usecount goes to 0 and then it's removed, which would explain > it. > >> Maybe NFSv4 has a cleaner way to keep a file with 0 links as long as it >> is open. >> > Afraid not. NFSv4 has an Open, but it is an open share lock and not a > POSIX style open, so NFSv4 clients still do the silly rename. (ie. The > NFSv4 Remove Op is defined as removing the file and not just unlinking > it and the NFSv4 server isn't required to retain the file after removal > if it is Open'd by a client.) > I'd like to pop this issue back to the top of the stack. Doing an installworld to local disks on a NFS-root system used to be a convenient way to install new systems without requiring release bits and release media. So, this used to work, and now it doesn't. I'd like help in getting to the bottom of this and fixing it. Scott