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
Received on Sat Sep 8 17:16:38 2012