> Yes, i know it's still possible to create an image which will be compacted not that efficiently, but this becomes quite a rare case.
But in irl - get random prodaction node and first container with max delta (data vs image size) - ploop-balloon discard /vz/private/93713/root.hdd/DiskDescriptor.xml --stat Balloon size: 0MB Data size: 30845MB Ploop size: 51200MB Image size: 47546MB ploop-balloon discard /vz/private/93713/root.hdd/DiskDescriptor.xml --defrag ... ploop-balloon discard /vz/private/93713/root.hdd/DiskDescriptor.xml --stat Balloon size: 0MB Data size: 30845MB Ploop size: 51200MB Image size: 47433MB And already have 17Gb wasted space for 30Gb data after compact with defrag. ( on node openvz 6 - 2.6.32-042stab114.5 kernel, ploop-1.15-1.x86_64 and e4defrag2 builded from https://github.com/dmonakhov/e2fsprogs/tree/e4defrag2 with commits from 16 May). In irl we have significan overhead on disk operations on compact ploop images. In irl we regular have ploop images which we cannot umount - https://bugs.openvz.org/browse/OVZ-6689 !!! And from time to time backup and compact failed with strange situations like - https://bugs.openvz.org/browse/OVZ-6547 2016-06-06 18:13 GMT+03:00 Konstantin Khorenko <khore...@virtuozzo.com>: > On 06/06/2016 02:23 PM, Volker Janzen wrote: > >> Hi Sergey, >> >> On 14:39 Sun 05 Jun , Volker Janzen wrote: >>> >>>> >>>>> Unfortunately no. We don't support upgrade from pre-release version to >>>>> the final one. >>>>> >>>> >>>> When I use a CentOS 7 as base system and install VZ7 afterward it's not >>>> possible to upgrade, too? >>>> >>> >>> There is only one supported configuration for new installations - >>> clean Virtuozzo 7 installation. >>> >> >> okay I see. My setup will be unsupported if installed on plain CentOS 7 >> either way. >> >> >>> It also seems to lack some documentation for my use cases, but I need to >>>>>> start >>>>>> with VZ7 sooner or later. >>>>>> >>>>> >>>>> What usecases are you talking about? >>>>> >>>> >>>> My current OpenVZ setup has LVM involved. >>>> I want to be able to use simfs based storage on an underlaying LVM >>>> volume. >>>> >>> >>> Why do you prefer simfs instead of ploop? Did you see comparison simfs >>> vs ploop? >>> https://openvz.org/CT_storage_backends >>> >> >> I think you asked me about this some time ago. The matrix states: >> Reliability >> Low: big amount of files produce ext4 corruption so often >> >> Why should I use something that tells me it's not reliable? >> > > Even according to > > https://github.com/pavel-odintsov/OpenVZ_ZFS/blob/master/openvz_storage_backends.md > (which seems to be used as a source of recent page update) this row is > incorrect, this info has just been added by Narcis Garcia and is to be > corrected. > > i don't want to start a holly war here, i won't tell that ZFS is worse or > whatever, > i just know that we really do power crash testing and know the results. > And i'm certain that our default suggested solution is good and stable. > > Yes, there are drawbacks - the most important one now is usage overhead > (sic!, not stability for a long time already), and we improve it. > And gained quite a good progress. Just did a ploop compaction of my > personal work Container, created 03.07.2014 (lot of gits, makes, etc.): > > # ploop-balloon discard /vz/private/105/root.hdd/DiskDescriptor.xml > --defrag > ... > # ploop-balloon discard /vz/private/105/root.hdd/DiskDescriptor.xml --stat > Balloon size: 0MB > Data size: 29189MB > Ploop size: 102400MB > Image size: 29057MB > > Yes, i know it's still possible to create an image which will be compacted > not that efficiently, but this becomes quite a rare case. > Do you have such an image? Send it to us. > > Thank you. > > P.S. in fact we don't need full image in most cases, only metadata is > essential, so if you worry about data and confidentiality, no problem here: > # e2image -r /dev/ploopXXp1 - | bzip2 > image.e2i.bz2 > > -- > Best regards, > > Konstantin Khorenko, > Virtuozzo Linux Kernel Team > > > The /vz partition has also the big advantage of using LVM snapshots and it >> allows rsync of the container data to another host with less overhead. >> >> Also the need to compress the ploop files does not seem to be something >> I'm willing to do. >> >> >> Regards >> Volker >> >> >>> And I want to be able to setup KVM based VMs that have a LVM based disk, >>>> too. >>>> In best case KVM VMs can be created from a template, as with the >>>> container VMs. >>>> >>> >>> Den, is it possible in Vz7? >>> >>> Regards >>>> Volker >>>> >>> _______________________________________________ > Users mailing list > Users@openvz.org > https://lists.openvz.org/mailman/listinfo/users >
_______________________________________________ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users
