On Fri, Nov 13, 2020 at 6:19 AM Chirantan Ekbote <chirantan@xxxxxxxxxxxx> wrote: > > On Tue, Nov 10, 2020 at 4:52 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > > > On Tue, Nov 10, 2020 at 4:33 AM Chirantan Ekbote <chirantan@xxxxxxxxxxxx> wrote: > > > > > That's not the behavior I observed. Without this, the O_TMPFILE flag > > > gets passed through to the server. The call stack is: > > > > > > - do_filp_open > > > - path_openat > > > - do_tmpfile > > > - vfs_tmpfile > > > - dir->i_op->tmpfile > > > - finish_open > > > - do_dentry_open > > > - f->f_op->open > > > > > > and I didn't see O_TMPFILE being removed anywhere in there. > > > > Ah, indeed. > > > > The reason I missed this is because IMO the way it *should* work is > > that FUSE_TMPFILE creates and opens the file in one go. We shouldn't > > need two separate request. > > > > Not sure how we should go about this... The ->atomic_open() API is > > sufficient, but maybe we want a new ->atomic_tmpfile(). > > > > I think I agree with you that it should probably be a single request > but at this point is it worth adding an ->atomic_tmpfile() that's only > used by fuse? Unlike regular file creation, it's not like the tmpfile > entry is accessible via any other mechanism so other than latency I > don't think there's any real harm with having it be 2 separate > requests. It's the wrong interface, and we'll have to live with it forever if we go this route. Better get the interface right and *then* think about the implementation. I don't think adding ->atomic_tmpfile() would be that of a big deal, and likely other distributed fs would start using it in the future. Thanks, Miklos
