From owner-freebsd-current@FreeBSD.ORG Wed Aug 12 14:17:12 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 18171106566C for ; Wed, 12 Aug 2009 14:17:12 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E0D768FC47 for ; Wed, 12 Aug 2009 14:17:11 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 46EDA46B2E; Wed, 12 Aug 2009 10:17:11 -0400 (EDT) Date: Wed, 12 Aug 2009 15:17:11 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Scott Long In-Reply-To: <4A81F443.5030905@samsco.org> Message-ID: References: <20090702121640.D245@maildrop.int.zabbadoz.net> <20090702122955.J245@maildrop.int.zabbadoz.net> <20090702212505.GA39889@stack.nl> <4A81F443.5030905@samsco.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 14:17:12 -0000 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. Robert N M Watson Computer Laboratory University of Cambridge