[Virtio-fs] [virtiofsd][virtiofsd-rs] unlink an openfile over NFS

[German Maglione]

On Wed, Dec 1, 2021 at 11:10 PM Vivek Goyal <vgoyal at redhat.com> wrote:

> On Wed, Dec 01, 2021 at 01:06:23PM +0100, German Maglione wrote:
> > Hi,
> >
> > I was working on [1] (related to [2]), and I saw that both versions
> > (C and rust) of virtiofsd make the NFs client to "silly rename" an open
> > file that were unlinked, because we keep each file open as O_PATH in the
> > lo_do_lookup/do_lookup function. David pointed me to this problem, and I
> > confirmed that this is the case.
> >
> > This fires the silly rename in the nfs client. I'm talking with
> > Bruce Fields (nfs team) to see how to move the silly rename functionality
> > to the nfs server and outside the directory tree [4], to avoid having
> > non-really-empty
> > dirs full of .nfsxxx files. But it is not an easy task.
> > Also, this will not solve some potential issues with the resource usage:
> > disk space and open file limits (I hit this limit a couple of times
> during
> > my
> > tests). And, in some cases could be worst, more than one guest sharing
> the
> > same
> > exported dir, one guest just 'ls' or 'find' while the other 'rm' some
> files.
> > (The 'find' command will open all files, btw)
> >
> > Vivek, I saw in [5] that you mentioned that this could be fixed
> introducing
> > synchronous, could you elaborate a bit or point me to some code?
>
> Hi German,
>
> Right now forget messages are asynchronous. They are sent to server and
> client does not wait for any reply. That means when unlink() returns,
> it is possible that a FORGET message is in progress and has not finished
> yet.
>
> Idea behind synchronous FORGET messages is that it will generate a reply
> and client will wait for it. Given inode on server should be gone,
> I am not sure how much sense does it make. But anyway conceputaully
> that's the idea. If we want for FORGET message to finish, that will
> mean that O_PATH fd opened by virtiofsd is closed and we will not
> have NFS silly rename issue (atleast due to virtiofsd). If virtiofs
> client has file open, then issue will still happen.
>
> I think using file handles in virtiofsd_rs (--inode-file-handles) is
> a reasonable solution for this problem. Trying to add synchronous
> FORGET might be overkill.
>
>
Hi Vivek,

Yes, as you said the solution is using --inode-file-hanldes, turns out
the problem was the --inode-file-handles failed silently when
choosing a sandbox other than namespace (now fixed by Hanna).

So now the thing is, what we do if it fails? Hanna posted an Issue about
that:
"[RFE] Reporting failure to generate file handles".

There is any problem to use file handles as default? I mean without
--inode-file-handles so let them fail and force the user to use something
like
--no-file-handles/--force-no-file-handles with a warning.


-- 
German
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/virtio-fs/attachments/20211202/64489e30/attachment.htm>