freeBSD nullfs together with nfs and "silly rename"

Mikolaj Golub to.my.trociny at gmail.com
Sat Jun 12 08:56:14 UTC 2010


On Sun, 6 Jun 2010 16:44:43 +0200 Leon Meßner wrote:

 LM> Hi,
 LM> I hope this is not the wrong list to ask. Didn't get any answers on
 LM> -questions.

 LM> When you try to do the following inside a nullfs mounted directory,
 LM> where the nullfs origin is itself mounted via nfs you get an error:

 LM> # foo 
 LM> # tail -f foo& 
 LM> # rm -f foo 
 LM> tail: foo: Stale NFS file handle
 LM> # fg

 LM> This is really a problem when running services inside jails and using
 LM> NFS as storage. As of [2] it looks like this problem is known for a
 LM> while. On a normal NFS mount this does not happen as "silly renaming"
 LM> [1] works there (producing nasty little .nfsXXXX files).

nfs_sillyrename() is called when vnode's usecount is more then 1. It is
expected that unlink() syscall increases vnode's usecount in namei() and if
the file has been already opened usecount will be more then 1.

But with nullfs layer present the reference counts are held by the upper node,
not the lower (nfs) one, so when unlink() is called it increases usecount of
the upper vnode, not nfs vnode and nfs_sillyrename() is never called.

The strightforward solution looks like to implement null_remove() that will
increase lower vnode's refcount before calling null_bypass() and then
decrement it after the call. See the attached patch (it works for me on both
8-STABLE and CURRENT).

-- 
Mikolaj Golub



More information about the freebsd-stable mailing list