User: Password:
|
|
Subscribe / Log in / New account

Shared inodes

Shared inodes

Posted Jun 17, 2011 16:14 UTC (Fri) by martinfick (subscriber, #4455)
In reply to: Shared inodes by neilbrown
Parent article: Debating overlayfs

> Assuming I am understanding you correctly.

So with overlayfs, if I have 1000 containers each with their own upper layer mounted separately on top of the same lower layer, and each one of them runs the same copy of apache, will the linux MM system share most of the memory for those apache executables, as much as if they all ran off of the same file in the lower layer directly?

If so, this will be a major boon for "virtualisation" on linux, extremely memory efficient and lightweight containers. This would allow linux containers in the mainline to share some of the ideas and similar benefits to the linux vserver project's "unification".


(Log in to post comments)

Shared inodes

Posted Jun 19, 2011 22:58 UTC (Sun) by Sho (subscriber, #8956) [Link]

Don't shared subtrees get you a long part of the way, too?

Shared inodes

Posted Jun 19, 2011 23:43 UTC (Sun) by neilbrown (subscriber, #359) [Link]

Shared subtrees are certainly part of the solution - and an important part.

If the Linux/Unix file hierarchy had been design with sufficient foresight (which would have been total impractical in reality) then you probably could do it all with shared subtrees. Those files that might need to be configure per-machine or per-instance would be in one subtree (a bit like /var maybe) and all the other files would be elsewhere. The one subtree would be copied for each instance, the rest would be shared.

But we don't have such a forward looking design .. and it is entirely possible that differing needs are such that such a design would be impossible. So configuration files are often mixed in with non-configuration files. A solution is needed which makes copies of the first type, but shares the second type.

One could imagine a forest-of-symlinks which could map all 'configuration' files into one subtree, but symlinks don't always (ever?) provide perfect semantics. If you update a config file by writing a new copy then renaming it, you break the symlink.

You could do the symlinks in the other direction: with symlinks for all the files that you want to share, but that would have it's own problems I suspect.

So overlayfs complements shared subtrees and allows you to selectively have some files shared and some files private within the same directory. And it achieved this almost transparently.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds