[PATCH v15 0/9] erofs: Introduce page cache sharing feature
Gao Xiang
hsiangkao at linux.alibaba.com
Sat Jan 17 03:30:08 AEDT 2026
On 2026/1/16 23:36, Christoph Hellwig wrote:
> Sorry, just getting to this from my overful inbox by now.
>
> On Fri, Jan 16, 2026 at 09:55:41AM +0000, Hongbo Li wrote:
>> 2.1. file open & close
>> ----------------------
>> When the file is opened, the ->private_data field of file A or file B is
>> set to point to an internal deduplicated file. When the actual read
>> occurs, the page cache of this deduplicated file will be accessed.
>
> So the first opener wins and others point to it? That would lead to
> some really annoying life time rules. Or you allocate a hidden backing
> file and have everyone point to it (the backing_file related subject
> kinda hints at that), which would be much more sensible, but then the
> above descriptions would not be correct.
Your latter thought is correct, I think the words above
are ambiguous.
>
>>
>> When the file is opened, if the corresponding erofs inode is newly
>> created, then perform the following actions:
>> 1. add the erofs inode to the backing list of the deduplicated inode;
>> 2. increase the reference count of the deduplicated inode.
>
> This on the other hand suggests the fist opener is used approach again?
Not quite sure about this part, assuming you read the
patches, it's just similar to the backing_file approach.
>
>> Assuming the deduplication inode's page cache is PGCache_dedup, there
>
> What is PGCache_dedup?
Maybe it's just an outdated expression from the older versions
from Hongzhen. I think just ignore this part.
>
>> Iomap and the layers below will involve disk I/O operations. As
>> described in 2.1, the deduplicated inode itself is not bound to a
>> specific device. The deduplicated inode will select an erofs inode from
>> the backing list (by default, the first one) to complete the
>> corresponding iomap operation.
>
> What happens for mmap I/O where folio->mapping is kinda important?
`folio->mapping` will just get the anon inode, but
(meta)data I/Os will submit to one of the real
filesystem (that is why a real inode is needed to
pass into iomap), and use the data to fill the
anon inode page cache, and the anon inode is like
backing_file, and vma->vm_file will point to the
hidden backing file backed by the anon inode .
Thanks,
Gao Xiang
>
> Also do you have a git tree for the whole feature?
More information about the Linux-erofs
mailing list