On Fri, Aug 28, 2020 at 11:01 PM Ken Schalk <kschalk@xxxxxxxxxx> wrote: > > On Aug 26, 2020 Ken Schalk <kschalk@xxxxxxxxxx> wrote: > > On Aug 21, 2020 Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > > On Thu, Aug 20, 2020 at 12:24 AM Ken Schalk <kschalk@xxxxxxxxxx> 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
