Hard links?

Posted Aug 16, 2024 13:06 UTC (Fri) by hsiangkao (subscriber, #123981)
In reply to: Hard links? by hsiangkao
Parent article: Memory-management: tiered memory, huge pages, and EROFS

>> Or is the patch more about sharing content between identical files in *different* filesystems? That seems much riskier. Suppose I have /dev/sda and /dev/sdb mounted on /mnt/foo and /mnt/bar, respectively. Let's suppose both filesystems are EROFS. One program opens /mnt/foo/my.txt and another, unrelated, program opens identical /mnt/bar/my.txt. AIUI, this patch silently re-routes the second open (for the file under /mnt/bar) to the inode already opened under /mnt/foo.
>> What happens when I surprise-remove /dev/sda? ISTM both programs would break, even though my expectation would be that only the program that opened /mnt/foo/my.txt would break and the program that opened /mnt/bar/my.txt would keep working.
> This patchset is still far from complete, ideally it needs an anonymous address_space for both identified inodes. If one instance unmounted, it will re-route to different source of another device.
> Sorry about the incomplete implementation so far due to his current kernel knowledge.

Also add some words, for the case you mentioned, there is nothing different from page-based page cache sharing and even page cache sharing within the same device (considering data link errors, various device mapper targets, and more);

That is, you turn on this page cache feature _only if_ you trust all data sources since each data source can contribute data to the system shared page cache.

to post comments

Hard links?

Posted Aug 16, 2024 14:38 UTC (Fri) by quotemstr (subscriber, #45331) [Link] (1 responses)

Thanks for the explanation. Super helpful; sounds like a nice feature once the kinks get worked out.

Another SQ: might it be possible to piggyback on top of fs-verity and make it general across filesystems --- at least read only ones? fs-verity already maintainers per file hashes in metadata, and fs-verity ensures that nobody's lying about what's in the file.

Also, have you considered some kind of "RAID 1" striped IO strategy? If I have block devices A and B with read only filesystems containing identical file X, why not read X from A and B in parallel? I can think of all sorts of fun things to do with the knowledge that two files on the same filesystem are identical.

Hard links?

Posted Aug 16, 2024 15:14 UTC (Fri) by hsiangkao (subscriber, #123981) [Link]

> Another SQ: might it be possible to piggyback on top of fs-verity and make it general across filesystems --- at least read only ones? fs-verity already maintainers per file hashes in metadata, and fs-verity ensures that nobody's lying about what's in the file.

I tend to keep this feature knob priviledged all the time (yeah, I know EROFS mounting needs priviledge). The priviledged user mount program could decide whether it uses dm-verity/fs-verity or other(TM) technologies to enable this feature safely (so we trust the priviledged user mount program.)

> Also, have you considered some kind of "RAID 1" striped IO strategy? If I have block devices A and B with read only filesystems containing identical file X, why not read X from A and B in parallel? I can think of all sorts of fun things to do with the knowledge that two files on the same filesystem are identical.

I guess it will be helpful (also it's still compatible if linux MM has a finer page-based page cache sharing
mechanism in the future), but I think let's make this feature work with the original use case first.

Also I think it would be better to reuse the current EROFS trusted domain id concept. I think all sources in the same trusted domain (e.g. from the same physical device, the same network host or a user-defined trusted array could form a domain) could share page cache safely, but even some sources from different trusted domain won't share by design.