On 2/1/24 15:52, Miklos Szeredi wrote:
> On Thu, 1 Feb 2024 at 15:36, Bernd Schubert <bernd.schubert@xxxxxxxxxxx> wrote:
>>
>>
>>
>> On 2/1/24 09:45, Miklos Szeredi wrote:
>>> On Thu, 1 Feb 2024 at 00:09, Bernd Schubert <bschubert@xxxxxxx> wrote:
>>>>
>>>> There were multiple issues with direct_io_allow_mmap:
>>>> - fuse_link_write_file() was missing, resulting in warnings in
>>>> fuse_write_file_get() and EIO from msync()
>>>> - "vma->vm_ops = &fuse_file_vm_ops" was not set, but especially
>>>> fuse_page_mkwrite is needed.
>>>>
>>>> The semantics of invalidate_inode_pages2() is so far not clearly defined
>>>> in fuse_file_mmap. It dates back to
>>>> commit 3121bfe76311 ("fuse: fix "direct_io" private mmap")
>>>> Though, as direct_io_allow_mmap is a new feature, that was for MAP_PRIVATE
>>>> only. As invalidate_inode_pages2() is calling into fuse_launder_folio()
>>>> and writes out dirty pages, it should be safe to call
>>>> invalidate_inode_pages2 for MAP_PRIVATE and MAP_SHARED as well.
>>>
>>> Did you test with fsx (various versions can be found in LTP/xfstests)?
>>> It's very good at finding mapped vs. non-mapped bugs.
>>
>> I tested with xfstest, but not with fsx yet. I can look into that. Do
>> you have by any chance an exact command I should run?
>
> Just specifying a filename should be good. Make sure you test with
> various open modes.
fsx immediately fails in FOPEN_DIRECT_IP mode ("passthrough_hp
--direct-io ...") on an unpatched kernel, but continues to run in
patched mode.
Given
-N numops: total # operations to do (default infinity)
How long do you think I should run it? Maybe something like 3 hours
(--duration=$(3 * 60 * 60))?
Thanks,
Bernd
