On Wed, Dec 1, 2021 at 11:10 PM Vivek Goyal <[email protected]> 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
_______________________________________________ Virtio-fs mailing list [email protected] https://listman.redhat.com/mailman/listinfo/virtio-fs
