Re: hard links across snapshots/subvolumes are actually a bad idea.

[Gordan Bobic <gordan@bobich.net>]

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