From owner-freebsd-current@FreeBSD.ORG Wed Aug 12 16:34:44 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 29159106566C; Wed, 12 Aug 2009 16:34:44 +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 CA4A18FC4D; Wed, 12 Aug 2009 16:34:43 +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 n7CGYa3w049993; Wed, 12 Aug 2009 10:34:36 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4A82EF1C.2090004@samsco.org> Date: Wed, 12 Aug 2009 10:34:36 -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: Robert Watson References: <20090702121640.D245@maildrop.int.zabbadoz.net> <20090702122955.J245@maildrop.int.zabbadoz.net> <20090702212505.GA39889@stack.nl> <4A81F443.5030905@samsco.org> 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.5 required=3.8 tests=ALL_TRUSTED,AWL,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" , Rick Macklem , 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: Wed, 12 Aug 2009 16:34:44 -0000 Robert Watson wrote: > > On Tue, 11 Aug 2009, Scott Long wrote: > >>> 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. > > Is this issue with the default NFS client, or the experimental one? If > the former, I'll put this on the RE known issues please solve thanks list. > Thanks to insight from Jilles, it looks like it's a sillyrename issue triggered by a change in src/Makefile.inc, and not an NFS bug. Scott