On Mon, Nov 6, 2023 at 4:08 PM Bernd Schubert
<bernd.schubert@xxxxxxxxxxx> wrote:
>
> Hi Miklos,
>
> On 9/20/23 10:15, Miklos Szeredi wrote:
> > On Wed, 20 Sept 2023 at 04:41, Tyler Fanelli <tfanelli@xxxxxxxxxx> wrote:
> >>
> >> At the moment, FUSE_INIT's DIRECT_IO_RELAX flag only serves the purpose
> >> of allowing shared mmap of files opened/created with DIRECT_IO enabled.
> >> However, it leaves open the possibility of further relaxing the
> >> DIRECT_IO restrictions (and in-effect, the cache coherency guarantees of
> >> DIRECT_IO) in the future.
> >>
> >> The DIRECT_IO_ALLOW_MMAP flag leaves no ambiguity of its purpose. It
> >> only serves to allow shared mmap of DIRECT_IO files, while still
> >> bypassing the cache on regular reads and writes. The shared mmap is the
> >> only loosening of the cache policy that can take place with the flag.
> >> This removes some ambiguity and introduces a more stable flag to be used
> >> in FUSE_INIT. Furthermore, we can document that to allow shared mmap'ing
> >> of DIRECT_IO files, a user must enable DIRECT_IO_ALLOW_MMAP.
> >>
> >> Tyler Fanelli (2):
> >> fs/fuse: Rename DIRECT_IO_RELAX to DIRECT_IO_ALLOW_MMAP
> >> docs/fuse-io: Document the usage of DIRECT_IO_ALLOW_MMAP
> >
> > Looks good.
> >
> > Applied, thanks. Will send the PR during this merge window, since the
> > rename could break stuff if already released.
>
> I'm just porting back this feature to our internal fuse module and it
> looks these rename patches have been forgotten?
>
>
Hi Miklos, Bernd,
I was looking at the DIRECT_IO_ALLOW_MMAP code and specifically at
commit b5a2a3a0b776 ("fuse: write back dirty pages before direct write in
direct_io_relax mode") and I was wondering - isn't dirty pages writeback
needed *before* invalidate_inode_pages2() in fuse_file_mmap() for
direct_io_allow_mmap case?
For FUSE_PASSTHROUGH, I am going to need to call fuse_vma_close()
for munmap of files also in direct-io mode [1], so I was considering installing
fuse_file_vm_ops for the FOPEN_DIRECT_IO case, same as caching case,
and regardless of direct_io_allow_mmap.
I was asking myself if there was a good reason why fuse_page_mkwrite()/
fuse_wait_on_page_writeback()/fuse_vma_close()/write_inode_now()
should NOT be called for the FOPEN_DIRECT_IO case regardless of
direct_io_allow_mmap?
I mean, maybe an unmap of a read-only private map does not need to
flush dirty pages (IDK), but caching mode seems to do it anyway?
Thanks,
Amir.
[1] https://lore.kernel.org/linux-fsdevel/CAJfpegtOt6MDFM3vsK+syJhpLMSm7wBazkXuxjRTXtAsn9gCuA@xxxxxxxxxxxxxx/
