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