Date: Sat, 12 Jun 2010 11:56:10 +0300 From: Mikolaj Golub <to.my.trociny@gmail.com> To: Leon =?utf-8?Q?Me=C3=9Fner?= <l.messner@physik.tu-berlin.de> Cc: freebsd-stable@freebsd.org Subject: Re: freeBSD nullfs together with nfs and "silly rename" Message-ID: <8639wsk4t1.fsf@kopusha.home.net> In-Reply-To: <20100606144443.GA50876@emmi.physik-pool.tu-berlin.de> ("Leon =?utf-8?Q?Me=C3=9Fner=22's?= message of "Sun, 6 Jun 2010 16:44:43 %2B0200") References: <20100606144443.GA50876@emmi.physik-pool.tu-berlin.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 6 Jun 2010 16:44:43 +0200 Leon Me=C3=9Fner 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=20 LM> # tail -f foo&=20 LM> # rm -f foo=20 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 no= de, 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). --=20 Mikolaj Golub
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8639wsk4t1.fsf>