[PATCH v15 5/9] erofs: introduce the page cache share feature

[Gao Xiang]

On 2026/1/22 16:33, Christoph Hellwig wrote:
> On Tue, Jan 20, 2026 at 03:19:21PM +0800, Gao Xiang wrote:
>>> It will be very hard to change unless we move to physical indexing of
>>> the page cache, which has all kinds of downside.s
>>
>> I'm not sure if it's really needed: I think the final
>> folio adaption plan is that folio can be dynamic
>> allocated? then why not keep multiple folios for a
>> physical memory, since folios are not order-0 anymore.
> 
> Having multiple folios for the same piece of memory can't work,
> at we'd have unsynchronized state.

Why not just left unsynchronized state in a unique way,
but just left mapping + indexing seperated.

Anyway, that is just a wild thought, I will not dig
into that.

> 
>> Using physical indexing sounds really inflexible on my
>> side, and it can be even regarded as a regression for me.
> 
> I'm absolutely not arguing for that..
> 
>>>> So that let's face the reality: this feature introduces
>>>> on-disk xattrs called "fingerprints." --- Since they're
>>>> just xattrs, the EROFS on-disk format remains unchanged.
>>>
>>> I think the concept of using a backing file of some sort for the shared
>>> pagecache (which I have no problem with at all), vs the imprecise
>>
>> In that way (actually Jingbo worked that approach in 2023),
>> we have to keep the shared data physically contiguous and
>> even uncompressed, which cannot work for most cases.
> 
> Why does that matter?

Sorry then, I think I don't get the point, but we really
need this for the complete page cache sharing on the
single physical machine.

> 
>> On the other side, I do think `fingerprint` from design
>> is much like persistent NFS file handles in some aspect
>> (but I don't want to equal to that concept, but very
>> similar) for a single trusted domain, we should have to
>> deal with multiple filesystem sources and mark in a
>> unique way in a domain.
> 
> I don't really thing they are similar in any way.

Why they are not similiar, you still need persistent IDs
in inodes for multiple fses, if there are a
content-addressable immutable filesystems working in
inodes, they could just use inode hashs as file handles
instead of inode numbers + generations.

Thanks,
Gao Xiang