Copy-on-write hard-links

Copy-on-write hard-links

[Gordan Bobic]

Is there a feature in btrfs to manually/explicitly mark hard-links to be 
copy-on-write? My understanding is that this is what happens when a 
snapshot is mounted rw and files modified.

Consider this scenario:

I have a base template fs. I make two snapshots of it that are 
identical. The files in the template and both snapshots are hard-links 
and have the same inode number.

I change a file in one of the snapshots, and it gets copied on write. I 
make the same change in the other snapshot, and that, too, gets copied 
on write. I now have two identical files that are not hard-links any more.

What happens if I remove one of those files and create a hard-link to 
the file in the other snapshot? Will this implicitly become a 
copy-on-write file or will the hard-link aspect in the traditional sense 
be preserved? If I modify the file, will it end up modified in both? Is 
there a way to explicitly set a COW flag (on a file with hard-links)?

The reason I am asking this is because I am looking into using either 
VServer or LXC virtualization. VServer has a "hashify" feature that 
works as I described (copy-on-write hard-linking identical files between 
multiple guests). But VServer isn't, and is unlikely to ever be in the 
mainline kernel. LXC is already in the mainline kernel, but relies on 
the FS to provide this functionality. For future proofing reasons, I 
would prefer to use LXC+btrfs, but hashify is too valuable a feature to 
sacrifice for staying with the mainline. Also note that simple 
block-level dedupe isn't sufficient for the full benefit in this context 
- hard-linking has the additional benefit that multiple copies of DLLs 
in multiple guests will not use separate memory when hard-linked (i.e. 
their inodes are the same). This equates to a very substantial memory 
saving (poor man's KSM) in addition to the disk space savings when there 
are many guests.

TIA.

Gordan

Re: Copy-on-write hard-links

[Chris Mason]

On Thu, Jun 10, 2010 at 06:11:40PM +0100, Gordan Bobic wrote:
> Is there a feature in btrfs to manually/explicitly mark hard-links
> to be copy-on-write? My understanding is that this is what happens
> when a snapshot is mounted rw and files modified.
> 
> Consider this scenario:
> 
> I have a base template fs. I make two snapshots of it that are
> identical. The files in the template and both snapshots are
> hard-links and have the same inode number.
> 
> I change a file in one of the snapshots, and it gets copied on
> write. I make the same change in the other snapshot, and that, too,
> gets copied on write. I now have two identical files that are not
> hard-links any more.
> 
> What happens if I remove one of those files and create a hard-link
> to the file in the other snapshot?

I'm afraid you can't do this.  hard linking between subvolumes isn't
allowed.  But, what you can do is use the clone ioctl to make a new
inode that references all of the data extents of an existing file, which
would be a kind of COW hard link.

Checkout bcp from btrfs-progs or cp --reflink from the latest..well
wherever cp comes from.

-chris

Re: Copy-on-write hard-links

[Gordan Bobic]

On 06/10/2010 09:00 PM, Chris Mason wrote:
> On Thu, Jun 10, 2010 at 06:11:40PM +0100, Gordan Bobic wrote:
>> Is there a feature in btrfs to manually/explicitly mark hard-links
>> to be copy-on-write? My understanding is that this is what happens
>> when a snapshot is mounted rw and files modified.
>>
>> Consider this scenario:
>>
>> I have a base template fs. I make two snapshots of it that are
>> identical. The files in the template and both snapshots are
>> hard-links and have the same inode number.
>>
>> I change a file in one of the snapshots, and it gets copied on
>> write. I make the same change in the other snapshot, and that, too,
>> gets copied on write. I now have two identical files that are not
>> hard-links any more.
>>
>> What happens if I remove one of those files and create a hard-link
>> to the file in the other snapshot?
>
> I'm afraid you can't do this.  hard linking between subvolumes isn't
> allowed.  But, what you can do is use the clone ioctl to make a new
> inode that references all of the data extents of an existing file, which
> would be a kind of COW hard link.
>
> Checkout bcp from btrfs-progs or cp --reflink from the latest..well
> wherever cp comes from.

Would the inodes on the clone file be the same for purposes of loading a 
dynamic library? Specifically, say the file I am cloning is a DLL. 
Normally, if a DLL is hard-linked, if two programs dynamically load it 
from two different hard-links, it'll still only use one bit of shared 
memory. Will this also hold true for the cloned files? My understanding 
is that it will not since it's not the same inode. Is that the case?

Thanks.

Gordan