[Users] ZFS vs ploop

[Kir Kolyshkin]

On 22 July 2015 at 19:44, Kir Kolyshkin <kir at openvz.org> wrote:

>
> Next thing, you can actually use shared base deltas for containers, and
> although it is not
> enabled by default, but quite possible and works in practice. The key is
> to create a base delta
> and use it for multiple containers (via hardlinks).
>
> Here is a quick and dirty example:
>
> SRCID=50 # "Donor" container ID
> vztmpl-dl centos-7-x86_64 # to make sure we use the latest
> vzctl create $SRCID --ostemplate centos-7-x86_64
>


Addition to this place:

     vzctl mount $SRCID
     sleep 20
     vzctl umount $SRCID


This is required because ploop uses lazy inode table initialization when
formatting ext4,
and it leads to inode table init (lots of writes) being done later, when
the container is first
mounted. If we don't mount it here and wait till it does its job, the code
below will multiply
the data written by a factor of 1000 which we don't want.

Also, Instead of "sleep 20" we could use something like

     while killall -0 ext4lazyinit; do sleep 1; done

to wait for real until lazy init finishes.



> vzctl snapshot $SRCID
> for CT in $(seq 1000 2000); do \
>       mkdir -p /vz/private/$CT/root.hdd /vz/root/$CT; \
>       ln /vz/private/$SRCID/root.hdd/root.hdd
> /vz/private/$CT/root.hdd/root.hdd; \
>       cp -nr /vz/private/$SRCID/root.hdd /vz/private/$CT/; \
>       cp /etc/vz/conf/$SRCID.conf /etc/vz/conf/$CT.conf; \
>    done
> vzctl set $SRCID --disabled yes --save # make sure we don't use it
>
> This will create 1000 containers (so make sure your host have enough RAM),
> each having about 650MB files, so 650GB in total. Host disk space used
> will be
> about 650 + 1000*1 MB before start (i.e. about 2GB) , or about 650 +
> 1000*30 MB
> after start (i.e. about 32GB). So:
>
> real data used inside containers near 650 GB
> real space used on hard disk is near 32 GB
>
> So, 20x disk space savings, and this result is reproducible. Surely it
> will get worse
> over time etc., and this way of using plooop is neither official nor
> supported/recommended,
> but it's not the point here. The points are:
>  - this is a demonstration of what you could do with ploop
>  - this shows why you shouldn't trust any numbers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/users/attachments/20150723/8e6a6e20/attachment.html>