Re: [Virtio-fs] [fuse-devel] 'FORGET' ordering semantics (vs unlink & NFS)

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Nikolaus Rath (Nikolaus@rath.org) wrote:
> On Jan 04 2021, "Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:
> > Hi,
> >   On virtio-fs we're hitting a problem with NFS, where
> > unlinking a file in a directory and then rmdir'ing that
> > directory fails complaining about the directory not being empty.
> >
> > The problem here is that if a file has an open fd, NFS doesn't
> > actually delete the file on unlink, it just renames it to
> > a hidden file (e.g. .nfs*******).  That open file is there because
> > the 'FORGET' hasn't completed yet by the time the rmdir is issued.
> 
> 
> Are you really talking about FORGET and file descriptors here? I always
> assumed that the kernel will only drop dentries (aka emit FORGET) when
> all fds are closed and never saw otherwise in practice.
> 
> Do you mean RELEASE rather than FORGET, or dentry rather than file descriptor?

<reads code again> I still think I mean FORGET, and deamons fd.

In the (passthrough_ll) daemon we have two fd's; if I've got this right
then RELEASE closes fi->fh (i.e. a normal fd) where as FORGET
will close inode->fd which is the O_PATH fd.

If the user was to do:

    1 touch a/x
    2 rm a/x
    3 rmdir a/x

They would close(2) the fd at the end of the touch; so I think that
would cause us to see the RELEASE - but we don't see the FORGET yet.
Only after the 'rm' when a/x shouldn't exist any more; then I think we
can get a FORGET and close our inode->fd

Dave

> Best,
> -Nikolaus
> 
> -- 
> GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
> 
>              »Time flies like an arrow, fruit flies like a Banana.«
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK