On Wed, Nov 29, 2023 at 11:39 PM Antonio SJ Musumeci <trapexit@xxxxxxxxxx> 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@xxxxxxxxxx> wrote: > >>> > >>> On Wed, 29 Nov 2023 at 16:52, Amir Goldstein <amir73il@xxxxxxxxx> 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.
