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.) rickReceived on Fri Jul 03 2009 - 17:39:42 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:51 UTC