Install from NFS onto NFS fails on amd64

[Scott Long]

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