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

[Hongbo Li]

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. :)

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
>>>
>