Date: Wed, 12 Aug 2009 10:34:36 -0600 From: Scott Long <scottl@samsco.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>, Rick Macklem <rmacklem@uoguelph.ca>, FreeBSD current mailing list <current@FreeBSD.org>, Jilles Tjoelker <jilles@stack.nl> Subject: Re: Install from NFS onto NFS fails on amd64 Message-ID: <4A82EF1C.2090004@samsco.org> In-Reply-To: <alpine.BSF.2.00.0908121516200.17186@fledge.watson.org> References: <20090702121640.D245@maildrop.int.zabbadoz.net> <20090702122955.J245@maildrop.int.zabbadoz.net> <20090702212505.GA39889@stack.nl> <Pine.GSO.4.63.0907031533250.15531@muncher.cs.uoguelph.ca> <4A81F443.5030905@samsco.org> <alpine.BSF.2.00.0908121516200.17186@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A82EF1C.2090004>