[PATCH RFC 2/4] erofs: introduce page cache share feature
Gao Xiang
hsiangkao at linux.alibaba.com
Sat Jul 5 20:58:21 AEST 2025
Hi Amir,
On 2025/7/5 16:25, Amir Goldstein wrote:
...
>
> 2. When is it ok to use the backing_file helpers?
>
> The current patch allocates a struct file with
> alloc_file_pseudo() and not a struct backing_file,
> so using the backing_file helpers is going to be awkward and
> misleading and I think in this case it will we wize to refrain
> from using a local var name backing_file.
>
> The thing that you need to ask yourself is do you want
> backing_file_set_user_path() for the erofs shared inode.
Yes, agreed, that should be improved as you said.
>
> That means, what do you want users to see when they
> look at /proc/self/map_files symlinks.
>
> With the current patch set I believe they will see a symlink to
> something like "[erofs_pcs_f]" for any mapped file
> which is somewhat odd.
Agreed.
>
> I think it would have been nice if users saw something like
> "[erofs_pcs_md5digest:XXXXXXX]"
But if we use `overlay.metacopy` for example, it's not
a string anymore. IOWs, I'd like to support binary
footprint too.
And I tend to avoid md5 calcuation or something in
the kernel. The kernel just uses footprint xattrs
instead.
> IMO, making the page cache dedupe visible in map_files is
> a very nice feature.
> > Overlayfs took the approach that users are expecting to see
> the actual path of the (non-anonymous) file that they mapped
> when looking at map_files symlinks.
> If you do not display the path to erofs mount in map_files,
> then lsof will not be able to blame a process with mapped files
> as the reason for keeping erofs mount busy.
I think users should see `the actual path` rather than
"[erofs_pcs_xxxxx]" too, but I don't have any chance to
check this part yet.
If it's possible for overlayfs, I guess it's possible for
erofs page cache sharing, maybe?
Thanks,
Gao Xiang
>
> Thanks,
> Amir.
More information about the Linux-erofs
mailing list