Re: [PATCH v2 1/2] FUSE: Implement atomic lookup + open

From: Miklos Szeredi
Date: Mon Apr 25 2022 - 03:38:21 EST


On Mon, 25 Apr 2022 at 07:26, Dharmendra Hans <dharamhans87@xxxxxxxxx> wrote:
>
> On Fri, Apr 22, 2022 at 8:59 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> >
> > On Tue, 22 Mar 2022 at 12:52, Dharmendra Singh <dharamhans87@xxxxxxxxx> wrote:
> > >
> > > From: Dharmendra Singh <dsingh@xxxxxxx>
> > >
> > > There are couple of places in FUSE where we do agressive
> > > lookup.
> > > 1) When we go for creating a file (O_CREAT), we do lookup
> > > for non-existent file. It is very much likely that file
> > > does not exists yet as O_CREAT is passed to open(). This
> > > lookup can be avoided and can be performed as part of
> > > open call into libfuse.
> > >
> > > 2) When there is normal open for file/dir (dentry is
> > > new/negative). In this case since we are anyway going to open
> > > the file/dir with USER space, avoid this separate lookup call
> > > into libfuse and combine it with open.
> > >
> > > This lookup + open in single call to libfuse and finally to
> > > USER space has been named as atomic open. It is expected
> > > that USER space open the file and fills in the attributes
> > > which are then used to make inode stand/revalidate in the
> > > kernel cache.
> > >
> > > Signed-off-by: Dharmendra Singh <dsingh@xxxxxxx>
> > > ---
> > > v2 patch includes:
> > > - disabled o-create atomicity when the user space file system
> > > does not have an atomic_open implemented. In principle lookups
> > > for O_CREATE also could be optimized out, but there is a risk
> > > to break existing fuse file systems. Those file system might
> > > not expect open O_CREATE calls for exiting files, as these calls
> > > had been so far avoided as lookup was done first.
> >
> > So we enabling atomic lookup+create only if FUSE_DO_ATOMIC_OPEN is
> > set. This logic is a bit confusing as CREATE is unrelated to
> > ATOMIC_OPEN. It would be cleaner to have a separate flag for atomic
> > lookup+create. And in fact FUSE_DO_ATOMIC_OPEN could be dropped and
> > the usual logic of setting fc->no_atomic_open if ENOSYS is returned
> > could be used instead.
>
> I am aware that ATOMIC_OPEN is not directly related to CREATE. But
> This is more of feature enabling by using the flag. If we do not
> FUSE_DO_ATOMIC_OPEN, CREATE calls would not know that it need to
> optimize lookup calls otherwise as we know only from open call that
> atomic open is implemented.

Right. So because the atomic lookup+crteate would need a new flag to
return whether the file was created or not, this is probably better
implemented as a completely new request type (FUSE_ATOMIC_CREATE?)

No new INIT flags needed at all, since we can use the ENOSYS mechanism
to determine whether the filesystem has atomic open/create ops or not.

Thanks,
Miklos