On Wed, Aug 31, 2022 at 5:20 AM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > Ref: https://lwn.net/Articles/896153/ > > On Wed, 31 Aug 2022 at 04:57, Yu-Li Lin <yulilin@xxxxxxxxxx> wrote: > > > > On Fri, Nov 13, 2020 at 2:54:46PM +0100, Miklos Szeredi wrote: > > > > > > On Fri, Nov 13, 2020 at 1:28 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > On Fri, Nov 13, 2020 at 11:52:09AM +0100, Miklos Szeredi wrote: > > > > > > > > > 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. > > > > > > > > Let me think about it; I'm very unhappy with the amount of surgery it has > > > > taken to somewhat sanitize the results of ->atomic_open() introduction, so > > > > I'd prefer to do it reasonably clean or not at all. > > > > > > The minimal VFS change for fuse to be able to do tmpfile with one > > > request would be to pass open_flags to ->tmpfile(). That way the > > > private data for the open file would need to be temporarily stored in > > > the inode and ->open() would just pick it up from there without > > > sending another request. Not the cleanest, but I really don't care as > > > long as the public interface is the right one. > > > > > > Thanks, > > > Miklos > > > > Resurrecting this old thread. Is there a conclusion on the addition of atomic_tmpfil() or vfs changes? > > > > Thanks, > > Yu-Li Lin Thanks for the reference. IIUC, the consensus is to make it atomic, although there's no agreement on how it should be done. Does that mean we should hold off on this patch until atomic temp files are figured out higher in the stack or do you have thoughts on how the fuse uapi should look like prior to the vfs/refactoring decision?
