Re: [PATCH v14 00/12] FUSE passthrough for file io

From: Amir Goldstein <amir73il@gmail.com>
To: Antonio SJ Musumeci <trapexit@spawn.link>
Cc: Bernd Schubert <bernd.schubert@fastmail.fm>,
	Miklos Szeredi <miklos@szeredi.hu>,
	 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, 30 Nov 2023 09:12:26 +0200	[thread overview]
Message-ID: <CAOQ4uxgWQbuiMQ5FaXyWALAXqdF-S2MrCLNB14-1ZYPfUs_d+g@mail.gmail.com> (raw)
In-Reply-To: <44ff6b37-7c4b-485d-8ebf-de5fadd3c527@spawn.link>

On Wed, Nov 29, 2023 at 11:39 PM Antonio SJ Musumeci
<trapexit@spawn.link> wrote:
>
> On 11/29/23 14:46, Bernd Schubert wrote:
> >
> >
> > On 11/29/23 18:39, Amir Goldstein wrote:
> >> On Wed, Nov 29, 2023 at 6:55 PM Miklos Szeredi <miklos@szeredi.hu> wrote:
> >>>
> >>> On Wed, 29 Nov 2023 at 16:52, Amir Goldstein <amir73il@gmail.com> wrote:
> >>>
> >>>> direct I/O read()/write() is never a problem.
> >>>>
> >>>> The question is whether mmap() on a file opened with FOPEN_DIRECT_IO
> >>>> when the inode is in passthrough mode, also uses fuse_passthrough_mmap()?
> >>>
> >>> I think it should.
> >>>
> >>>> or denied, similar to how mmap with ff->open_flags & FOPEN_DIRECT_IO &&
> >>>> vma->vm_flags & VM_MAYSHARE) && !fc->direct_io_relax
> >>>> is denied?
> >>>
> >>> What would be the use case for FOPEN_DIRECT_IO with passthrough mmap?
> >>>
> >>
> >> I don't have a use case. That's why I was wondering if we should
> >> support it at all, but will try to make it work.
> >
> > What is actually the use case for FOPEN_DIRECT_IO and passthrough?
> > Avoiding double page cache?
> >
> >>
> >>>> A bit more challenging, because we will need to track unmounts, or at
> >>>> least track
> >>>> "was_cached_mmaped" state per file, but doable.
> >>>
> >>> Tracking unmaps via fuse_vma_close() should not be difficult.
> >>>
> >>
> >> OK. so any existing mmap, whether on FOPEN_DIRECT_IO or not
> >> always prevents an inode from being "neutral".
> >>
> >
> >
> > Thanks,
> > Bernd
> >
>
>  > Avoiding double page cache?
>
> Currently my users enable direct_io because 1) it is typically
> materially faster than not 2) avoiding double page caching (it is a
> union filesystem).
>
> The only real reason people disable direct_io is because many apps need
> shared mmap. I've implemented a mode to lookup details about the
> requesting app and optionally disable direct_io for apps which are known
> to need shared mmap but that isn't ideal. The relaxed mode being
> discussed would likely be more performant and more transparent to the
> user. That transparency is nice if that can continue as it is already
> pretty difficult to explain all these options to the layman.
>
> Offtopic: What happens in passthrough mode when an error occurs?

passthrough is passthrough, in sickness and in health...

whatever read/write/splice on the real file returns, that is what application
will get for read/write/splice on the fuse file.

Regarding passthrough mmap - this means that the memory is really
mapped to the real file (in sickness and in health...).

The semantics of whether we do "normal" mmap or passthrough mmap
on a file that the server opened as FOPEN_DIRECT_IO will be:

If there is any file open for passthrough on this inode, mmap() will be to
the real inode page cache, regardless of FOPEN_DIRECT_IO.

Otherwise, whether there is a file open in cached mode or not, mmap()
will be to fuse inode page cache, regardless of FOPEN_DIRECT_IO.

Thanks,
Amir.