Re: [PATCH v15 0/9] erofs: Introduce page cache sharing feature

[Gao Xiang <hsiangkao@linux.alibaba.com>]

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?