Date: Wed, 28 Oct 2009 19:15:51 +0200 From: Gleb Kurtsou <gleb.kurtsou@gmail.com> To: Linda Messerschmidt <linda.messerschmidt@gmail.com> Cc: Andrey Simonenko <simon@comsys.ntu-kpi.kiev.ua>, freebsd-hackers@freebsd.org Subject: Re: FreeBSD 7.2 + NFS + nullfs + unlink + fstat = Stale NFS File Handle Message-ID: <20091028171550.GA1909@tops> In-Reply-To: <237c27100910280648k597e2159sf4fd663fe7b77b3b@mail.gmail.com> References: <237c27100910271013s1d8602d0l74d7d9d2c137adee@mail.gmail.com> <20091028124832.GA7852@pm513-1.comsys.ntu-kpi.kiev.ua> <237c27100910280648k597e2159sf4fd663fe7b77b3b@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On (28/10/2009 09:48), Linda Messerschmidt wrote:
> On Wed, Oct 28, 2009 at 8:48 AM, Andrey Simonenko
> <simon@comsys.ntu-kpi.kiev.ua> wrote:
> > As I understand when a file is opened in NULLFS its vnode gets new
> > reference on 'count of users', but this new reference is not propagated
> > to the lower vnode (vnode that is under NULLFS). When a file is removed
> > NULLFS passes this op to the lower FS (NFS in this example) and that
> > FS sees that its vnode has only a single reference on 'count of users'.
> >
> > In case of NFS when there is a request to remove a vnode it checks that
> > value of 'count of users' for this vnode. If this count is equal to 1,
> > then NFS client code does 'RPC remove'. If this count is greater than 1
> > (for example when a file is opened), then NFS client code renames pathname
> > to .nfs-file, but does not send 'RPC remove' to the NFS server.
>
> That sounds like a pretty reasonable explanation of what's going on.
>
> Unfortunately it does sound like this would be tough to fix. Since
> NFS deletes are a special case, short of making an NFS-aware nullfs,
> which seems silly, it sounds like the "solution" would be rewriting
> nullfs to propagate the reference count. I don't know enough about
> nullfs to know exactly how hard that would be, but I'm guessing it's
> not the work of a lazy afternoon. :-)
I think that's not about nullfs. Nullfs behaves correctly. It grabs
reference for a vnode and even tries too release it as soon as possible.
NFS logic is wrong here, imho. vrefcnt(vp) == 1 supposed to mean that
vnode is going to be reclaimed on next reference release and nothing
more. And it doesn't mean that reference is going to be released any
time soon. Although network filesystems in the tree abuse it the same
way NFS does.
Probably what NFS tries to do is to check if file descriptor is opened
for a vnode. This assumption holds only for a single code path out of
many: syscall by user. But there is plenty of code invoking vnode
operations without even allocating file descriptor.
Propagating per file descriptor reference counting into filesystem
itself is a layer violation and should be avoided in my opinion. There
should be a way to fix NFS by replacing vrefcnt check.
> >> if (!fd) {
> > ^^^^^ should be (fd < 0)
>
> Oops, you are right!
>
> Thanks very much!
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091028171550.GA1909>