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. ScottReceived on Wed Aug 12 2009 - 14:34:44 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:53 UTC