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