All of lore.kernel.org
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Bernd Schubert <bernd.schubert@fastmail.fm>,
	Daniel Rosenberg <drosen@google.com>,
	 Paul Lawrence <paullawrence@google.com>,
	Alessio Balsini <balsini@android.com>,
	 Christian Brauner <brauner@kernel.org>,
	fuse-devel@lists.sourceforge.net,  linux-fsdevel@vger.kernel.org,
	Dave Chinner <david@fromorbit.com>
Subject: Re: [PATCH v14 00/12] FUSE passthrough for file io
Date: Thu, 2 Nov 2023 15:07:58 +0200	[thread overview]
Message-ID: <CAOQ4uxjc6B2kXvbnbYPNCr8+ysFCoH24s+3fFa_Xkapyb9ueKA@mail.gmail.com> (raw)
In-Reply-To: <CAJfpegs5m-7QapX86CEiyy5oDzJQox6QsWjcLeegMV9OMbkBrg@mail.gmail.com>

On Thu, Nov 2, 2023 at 12:46 PM Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> >
> > Remember that we would actually need to do backing_file_open()
> > for all existing open files of the inode.
>
> I know.
>
> > Also, after the server calls FUSE_DEV_IOC_BACKING_CLOSE,
> > will the fuse_backing object still be referenced from the inode
> > (as it was in v13)? and then properly closed only on the last file
> > close on that inode?
>
> Yes, those seem the most intuitive semantics.
>

Just to be clear, at the last close for an inode, we would check
if attribute cache needs to be invalidate and the inode will return
to "neutral" mode, when server could legally switch between
caching and passthrough mode.

This part is critical to my in-house server, because when files are
not open, their content may become evicted and they may no longer
be passed through to.

> > I am not convinced that this complexity is a must for the first version.
> > If the server always sets FOPEN_PASSTHROUGH (as I expect many
> > servers will) this is unneeded complexity.
> >
> > It seems a *lot* easier to do what you suggested and ignore
> > FOPEN_PASSTHROUGH if the server is not being consistent
> > with the FOPEN_ flags it uses.
>
> The problem with ignoring is that we can't change the semantics later.
>
> So I think it would be better to enforce consistency such that if
> there's already an open file, new open files will have to have the
> same FOPEN_PASSTHROUGH state, and just reject with EIO if not.
>

EIO works for me.
Just as simple.
Will try to get this ready for early 6.8 cycle.

Thanks,
Amir.

  reply	other threads:[~2023-11-02 13:08 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-16 16:08 [PATCH v14 00/12] FUSE passthrough for file io Amir Goldstein
2023-10-16 16:08 ` [PATCH v14 01/12] fs: prepare for stackable filesystems backing file helpers Amir Goldstein
2023-10-16 16:08 ` [PATCH v14 02/12] fs: factor out backing_file_{read,write}_iter() helpers Amir Goldstein
2023-10-16 16:08 ` [PATCH v14 03/12] fs: factor out backing_file_splice_{read,write}() helpers Amir Goldstein
2023-10-16 16:08 ` [PATCH v14 04/12] fs: factor out backing_file_mmap() helper Amir Goldstein
2023-10-16 16:08 ` [PATCH v14 05/12] fuse: factor out helper for FUSE_DEV_IOC_CLONE Amir Goldstein
2023-10-16 16:08 ` [PATCH v14 06/12] fuse: introduce FUSE_PASSTHROUGH capability Amir Goldstein
2023-10-16 16:08 ` [PATCH v14 07/12] fuse: pass optional backing_id in struct fuse_open_out Amir Goldstein
2023-10-16 16:08 ` [PATCH v14 08/12] fuse: implement ioctls to manage backing files Amir Goldstein
2023-10-17  9:45   ` Amir Goldstein
2023-10-16 16:08 ` [PATCH v14 09/12] fuse: implement read/write passthrough Amir Goldstein
2023-10-16 16:09 ` [PATCH v14 10/12] fuse: implement splice_{read/write} passthrough Amir Goldstein
2023-10-16 16:09 ` [PATCH v14 11/12] fuse: implement passthrough for mmap Amir Goldstein
2023-10-16 16:09 ` [PATCH v14 12/12] fuse: implement passthrough for readdir Amir Goldstein
2023-10-19 14:33 ` [PATCH v14 00/12] FUSE passthrough for file io Amir Goldstein
2023-10-30 10:16   ` Miklos Szeredi
2023-10-31 10:28     ` Amir Goldstein
2023-10-31 11:16       ` Miklos Szeredi
2023-10-31 12:31         ` Amir Goldstein
2023-10-31 15:01           ` Miklos Szeredi
2023-10-31 17:44             ` Amir Goldstein
2023-11-01 11:32               ` Miklos Szeredi
2023-11-01 13:23                 ` Amir Goldstein
2023-11-01 14:42                   ` Miklos Szeredi
2023-11-01 15:06                     ` Amir Goldstein
2023-11-01 15:25                       ` Miklos Szeredi
2023-11-01 18:32                         ` Amir Goldstein
2023-11-02 10:46                           ` Miklos Szeredi
2023-11-02 13:07                             ` Amir Goldstein [this message]
2023-11-02 13:13                               ` Miklos Szeredi
2024-01-26 12:13                                 ` Amir Goldstein
2023-11-29  7:25                     ` Amir Goldstein
2023-11-29 14:13                       ` Miklos Szeredi
2023-11-29 15:06                         ` Amir Goldstein
2023-11-29 15:21                           ` Miklos Szeredi
2023-11-29 15:52                             ` Amir Goldstein
2023-11-29 16:55                               ` Miklos Szeredi
2023-11-29 17:39                                 ` Amir Goldstein
2023-11-29 20:46                                   ` Bernd Schubert
2023-11-29 21:39                                     ` Antonio SJ Musumeci
2023-11-29 22:01                                       ` Bernd Schubert
2023-11-30  7:29                                         ` Amir Goldstein
2023-11-30  7:12                                       ` Amir Goldstein
2023-11-30  8:17                                         ` Miklos Szeredi
2023-12-06  9:59                                 ` Amir Goldstein
2023-12-06 23:11                                   ` Bernd Schubert
2023-12-07  7:23                                     ` Amir Goldstein
2023-12-07  8:56                                       ` Bernd Schubert

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=CAOQ4uxjc6B2kXvbnbYPNCr8+ysFCoH24s+3fFa_Xkapyb9ueKA@mail.gmail.com \
    --to=amir73il@gmail.com \
    --cc=balsini@android.com \
    --cc=bernd.schubert@fastmail.fm \
    --cc=brauner@kernel.org \
    --cc=david@fromorbit.com \
    --cc=drosen@google.com \
    --cc=fuse-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=paullawrence@google.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.