Re: [fuse-devel] Cross-host entry caching and file open/create

[Miklos Szeredi <miklos@szeredi.hu>]

On Fri, Aug 28, 2020 at 11:01 PM Ken Schalk <kschalk@nvidia.com> wrote:
>
> On Aug 26, 2020 Ken Schalk <kschalk@nvidia.com> wrote:
> > On Aug 21, 2020 Miklos Szeredi <miklos@szeredi.hu> wrote:
> > > On Thu, Aug 20, 2020 at 12:24 AM Ken Schalk <kschalk@nvidia.com> wrote:
> > > > If the open flags include O_EXCL, then we're seeing a failure
> > > > with EEXIST without any call to our FUSE filesystem's create
> > > > operation (or any other FUSE operations).  The kernel makes this
> > > > failure decision based on its cached information about the
> > > > previously accessed (now deleted) file.  If the open flags do
> > > > not include O_EXCL, then we're seeing a failure with ENOENT from
> > > > our open operation (because the file does not actually exist
> > > > anymore), with no call to our create operation (because the
> > > > kernel believed that the file existed, causing it to make a FUSE
> > > > open request rather than a FUSE create request).
>
> > > Does the attached patch fix it?
>
> > Thanks very much for your help.  The patch you provided does solve
> > the problem in the O_CREAT|O_EXCL case (by making a lookup call to
> > re-validate the entry of the since deleted file), but not in the
> > O_CREAT case.  (In that case the kernel still winds up making a FUSE
> > open request rather than a FUSE create request.)  I'd like to
> > suggest the slightly different attached patch instead, which
> > triggers re-validation in both cases.

Which is a problem, because that makes O_CREAT on existing files (a
fairly common case) add a new synchronous request, possibly resulting
in a performance regression.

I don't see an easy way this can be fixed, and I'm not sure this needs
to be fixed.

Are you seeing a real issue with just O_CREAT?

Thanks,
Miklos