Subject: Re: [vserver] btrfs/hashify/cow....
From: Gordan Bobic <gordan@bobich.net>
Date: Sat, 08 Sep 2012 17:16:26 +0100

On 09/08/2012 11:10 AM, Tor Rune Skoglund wrote:
> 2012/9/7 Gordan Bobic<gordan@bobich.net>:
>> On 09/07/2012 04:11 PM, Tor Rune Skoglund wrote:
>>> I been trying to read up on the hashify with COW feature of vserver.
>>> Still some questions...:
>>>
>>> - What are the actual requirements for using this feature?
>>> - Any particular file systems only?
>>
>> IIRC only ext* file systems are supported/patched (included in the vserver
>> patch).
>>
>>> - Presumably, all hashifed files must reside on the same partition?
>>
>> Indeed, they must all be on the same file system.
>
> Additional ?: The host run on a partition of it own. The guests on
> another partition. So then the host is left out of the hashify
> process, but the guests still can be hashified towards "eachother" ?

All that is required is that your /vservers/ directory is on a single 
file system. The host file system is unrelated. Only the guests get 
mutually hashified, not the host.

>> Normally memory deduplication is very expensive in terms of CPU time, but in
>> vserver with hashify you get it for free.
>>
>>> - Can btrfs be used with vserver?
>>
>> Not unless somebody write the CoW hard-link patches recently.
>
> OK, so if btrfs is selected, then the vserver solution with
> hashify+CoW is out of reach.

I never tried it, so I cannot comment either way. After the BTRFS devs 
didn't manage to understand why CoW hard-links would be useful as a FS 
feature (without vserver), and after some of the comments they made 
regarding deduplication features and how (and whether) they plan to 
implement it in BTRFS, I made a firm decision I'm not going to touch it 
with a barge-pole. Ever. If these are the people designing and 
developing the FS, I'm not prepared to entrust my data to it. Where my 
requirements are feature-rich, I have switched to ZFS (ZFS-on-Linux 
kernel driver, not the fuse implementation) and never looked back. I 
still think it was the right decision.

>>> - What about trebuchet (http://wiki.baserock.org/Trebucket ): Any
>>> qualified guesses whether it will be compatible for updating a vserver
>>> guest? (USE-CASE: Update a guest as an atomic operation; keep fallback
>>> vserver guest ready in case update process incomplete, or in case new
>>> vserver guest do not perform correctly.)
>>
>> That link seems to be dead, and I cannot figure out from paragraph context
>> alone what it's supposed to achieve. Please elaborate?
>
> Sorry, my explanation was incomplete. And the link lacks the /, so it
> is actually http://wiki.baserock.org/Trebuchet/ .
>
> Our use-case is a distributed system. We need to update a vserver
> client as an atomic operation (and the host, by that is another
> issue...)
> More detailed, we would want to download a new "version" of the
> vserver client as a delta that will "update" the current installation,
> but keeping the possibility to revert to the pre-updated one in case
> the update fails or if the vserver client is some way do not work
> correctly or whatever reason. Trebuchet seems to offer that (probably
> with some addition development and setup), BUT relies on btrfs.
>
> So my initial point was; if we go down the Trebuchet road, then we
> need to use btrfs, and then we will not be able to use vservers
> hashify function (but still be able to have vserver without hashify).
> Presumable my reasoning for that is correct?

If I had to guess, it would be that Trebuchet uses snapshots to achieve 
this. You could achieve the same functionality using LVM underneath 
ext*. (Just bear in mind the alignment and LVM header sizes if you use 
it on alignment sensitive media, e.g. 4KB sector disks, SSDs with 
various erase block sizes, etc.)

Gordan