On Thu, 2 Jul 2009, Jilles Tjoelker wrote:

quoted text
>
> 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.

quoted text
> 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.)

rick
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"