From: Yu-li Lin <yulilin@google.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: chirantan@chromium.org, dgreid@chromium.org,
fuse-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org,
suleiman@chromium.org, viro@zeniv.linux.org.uk
Subject: Re: [PATCH 2/2] fuse: Implement O_TMPFILE support
Date: Wed, 31 Aug 2022 14:30:40 -0700 [thread overview]
Message-ID: <CAMW0D+epkBMTEzzJhkX7HeEepCH=yxJ-rytnA+XWQ8ao=CREqw@mail.gmail.com> (raw)
In-Reply-To: <CAJfpegvMGxigBe=3tgwBRKuSS0H1ey=0WhOkgOz5di-LqXH-HQ@mail.gmail.com>
On Wed, Aug 31, 2022 at 5:20 AM Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> Ref: https://lwn.net/Articles/896153/
>
> On Wed, 31 Aug 2022 at 04:57, Yu-Li Lin <yulilin@google.com> 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@zeniv.linux.org.uk> 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?
next prev parent reply other threads:[~2022-08-31 21:30 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-09 10:03 [PATCH 0/2] Support for O_TMPFILE in fuse Chirantan Ekbote
2020-11-09 10:03 ` [PATCH 1/2] uapi/fuse.h: Add message definitions for O_TMPFILE Chirantan Ekbote
2020-11-09 10:03 ` [PATCH 2/2] fuse: Implement O_TMPFILE support Chirantan Ekbote
2020-11-09 11:37 ` Miklos Szeredi
2020-11-10 3:33 ` Chirantan Ekbote
2020-11-10 7:52 ` Miklos Szeredi
2020-11-13 5:19 ` Chirantan Ekbote
2020-11-13 10:52 ` Miklos Szeredi
2020-11-13 12:28 ` Al Viro
2020-11-13 13:54 ` Miklos Szeredi
2022-08-31 2:57 ` Yu-Li Lin
2022-08-31 12:19 ` Miklos Szeredi
2022-08-31 21:30 ` Yu-li Lin [this message]
2022-09-05 15:51 ` Miklos Szeredi
2022-09-06 4:58 ` Amir Goldstein
2022-09-06 5:29 ` Al Viro
2022-09-06 7:23 ` Miklos Szeredi
2022-09-13 1:51 ` Al Viro
2022-09-13 10:20 ` Miklos Szeredi
2022-09-18 13:17 ` [fuse-devel] " Stef Bon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMW0D+epkBMTEzzJhkX7HeEepCH=yxJ-rytnA+XWQ8ao=CREqw@mail.gmail.com' \
--to=yulilin@google.com \
--cc=chirantan@chromium.org \
--cc=dgreid@chromium.org \
--cc=fuse-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=suleiman@chromium.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).