On 11/24/2010 10:07 PM, David Nicol wrote:
I've been thinking about this for a while, from a perspective of how
to make it work by allocating i-node numbers from a global pool, but
yesterday I realized that offering the feature would be a bad idea
because it violates the semantics of file systems.
I will be happy to expand on that point if anyone disagrees with it.
One thing I would like to see is copy-on-write hard-links. The
hard-links that span snapshots should be possible, but they should be
copy-on-write, i.e. as soon as hard-linked file that spans snapshots is
written, the snapshot that wrote it should have it's own forked copy
henceforth.
This would be immensely useful for things like virtualization and memory
saving. Not only would it save memory in the caches, but if multiple
instances of the same OS are used in LXC containers cloned using
snapshots, then two DLLs with the same inode number would mmap into the
same memory segment. That means that no matter how many VMs you run, if
they have the same DLLs, the memory requirement for all those would be
the same as if there was only one VM running.
Linux Vserver does exactly this (it patches several of the FS drivers to
add this feature. This is pretty much the only reason why I use it
instead of the already merged LXC.
Gordan
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
