From: Antonio SJ Musumeci <trapexit@spawn.link>
To: Bernd Schubert <bernd.schubert@fastmail.fm>,
Amir Goldstein <amir73il@gmail.com>,
Miklos Szeredi <miklos@szeredi.hu>
Cc: 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: Wed, 29 Nov 2023 21:39:21 +0000 [thread overview]
Message-ID: <44ff6b37-7c4b-485d-8ebf-de5fadd3c527@spawn.link> (raw)
In-Reply-To: <2f6513fa-68d8-43c8-87a4-62416c3e1bfd@fastmail.fm>
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?
Currently I have a number of behaviors relying on the fact that I can
intercept and respond to errors. I think my users will gladly give them
up for near native io perf but if they can get both it would be nice.
next prev parent reply other threads:[~2023-11-29 21:39 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
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 [this message]
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=44ff6b37-7c4b-485d-8ebf-de5fadd3c527@spawn.link \
--to=trapexit@spawn.link \
--cc=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.