[PATCH RFC] erofs: file-backed mount supports direct io
Hongbo Li
lihongbo22 at huawei.com
Mon Jan 20 14:43:21 AEDT 2025
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.
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
>
More information about the Linux-erofs
mailing list