[PATCH RFC] erofs: file-backed mount supports direct io

[Gao Xiang]

On 2025/1/20 14:16, Hongbo Li wrote:
> 
> 
> On 2025/1/20 11:46, Gao Xiang wrote:
>>
>>
>> On 2025/1/20 11:43, Hongbo Li wrote:
>>>
>>>
>>> On 2025/1/20 11:10, Gao Xiang wrote:
>>>>
>>>>
>>>> On 2025/1/20 11:02, Hongbo Li wrote:
>>>>>
>>>>>
>>>>
>>>> ...
>>>>
>>>>>>>   }
>>>>>>> +static int erofs_fileio_scan_iter(struct erofs_fileio *io, struct kiocb *iocb,
>>>>>>> +                  struct iov_iter *iter)
>>>>>>
>>>>>> I wonder if it's possible to just extract a folio from
>>>>>> `struct iov_iter` and reuse erofs_fileio_scan_folio() logic.
>>>>> Thanks for reviewing. Ok, I'll think about reusing the erofs_fileio_scan_folio logic in later version.
>>>>
>>>> Thanks.
>>>>
>>>>>
>>>>> Additionally, for the file-backed mount case, can we consider removing the erofs's page cache and just using the backend file's page cache? If in this way, it will use buffer io for reading the backend's mounted files in default, and it also can decrease the memory overhead.
>>>>
>>>> I think it's too hacky for upstreaming, since EROFS can only
>>>> operate its own page cache, otherwise it should only support
>>>> overlayfs-like per-inode sharing.
>>>>
>>>> Per-extent sharing among different filesystems is too hacky
>>> It just like the dax mode of erofs (but instead of the dax devices, it's a backend file). It does not share the page among the different filesystems, because there is only the backend file's page cache. I found the whole io path is similar to this direct io mode.
>>
>> How do you handle a VMA which is consecutive as an
>> EROFS file, but actually mapping to different part
>> of the underlay inode, or even different underlay
>> inodes?
> 
> The mmap is indeed a trouble, I'm still trying to figure out how to solve it. :)

Actually I don't think it's a clean feature, also
the upcoming page cache sharing feature already covers
the related use cases.

Thanks,
Gao Xiang

> 
> Thanks,
> Hongbo
> 
>>
>> It just cause the current MM layer broken, but FSDAX
>> mode is a complete different story.
>>
>> Thanks,
>> Gao Xiang
>>
>>>
>>> Thanks,
>>> Hongbo
>>>
>>>> on the MM side, but if you have some detailed internal
>>>> requirement, you could implement downstream.
>>>>
>>>> Thanks,
>>>> Gao Xiang
>>>>
>>>>>
>>>>> This is just my initial idea, for uncompressed mode, this should make sense. But for compressed layout, it needs to be verified.
>>>>>
>>>>> Thanks,
>>>>> Hongbo
>>>>>
>>>>>>
>>>>>> It simplifies the codebase a lot, and I think the performance
>>>>>> is almost the same.
>>>>>>
>>>>>> Otherwise currently it looks good to me.
>>>>>>
>>>>>> Thanks,
>>>>>> Gao Xiang
>>>>
>>