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. I'm going to make one additional suggestion here, included in the attached patch: always re-validate a negative entry for file open. This is sort of the dual of the problem of a file recently unlinked on a remote host, as it involves a file recently created on a remote host. If the kernel has cached a negative dentry, it will fail an open system call without any FUSE requests up to the user-space end. This patch gives the user-space side the opportunity to report that a file that previously did not exist has recently been created. (In distributed build automation workloads, opening a file recently created through a mount on a peer host is pretty common.) I would say that this brings the open system call behavior under FUSE into line with what we observe on NFS for cases where a file has been recently created or unlinked on a remote host. --Ken Schalk
Attachment:
fuse-reval-create-or-open-negative.patch
Description: fuse-reval-create-or-open-negative.patch
