Hello! Because your question is very big I will try to answer in multiple blocks :)
--- My disk space issue. 24GB is a wasted space from only one container :) Total wasted space per server is about 900Gb and it's really terrible for me. Why? Because I use server SSD with hardware RAID array's and cost per TB is cosmic! I want to give more fast space to customers instead wasting it! :) --- What I want. What I want from OpenVZ community? I want share my positive experience and build strong community of runners ZFS together with OpenVZ :) Well, I still have one question to openvz team related with behavior of vzctl which is important for ZFS (and another fs too): https://bugzilla.openvz.org/show_bug.cgi?id=3166 --- License issues of ZFS. License issues is not an critical because installing of ZFS is straightforward and do not require any deep integration to system or kernel and work on almost any kernel. And we can call zfs tools (zpool, zfs) without any problems with CDDL license of ZFS. But we can't link to libzfs and fortunately we do not need this. --- Ploop/ext4 vs ZFS ploop builded on top of ext4 and I compare ZFS with ploop and ext4 and many issues notified in my table related with features of both them. Obviously, it's completely incorrect to compare ploop (block level mapper device) with classic filesystem. --- Conclusion Globally, my speech is not related with ZFS itself. It's about storage system for containers. It's most important part of any virtualization technology. Ploop is real revolution in containers world! I really appreciate developers of ploop and love them (and will be happy to bring some beer to they) :) But ploop is not a final step of storage system for containers. And it have big problems described here: https://github.com/pavel-odintsov/OpenVZ_ZFS/blob/master/ploop_issues.md and everybody should know this issues. Ignoring this issues will produce complete data loss on important data! ZFS is not ideal filesystem for containers too! It lacks of very big amount of very important features but it's more reliable and featureful than ploop/ext4 :) Thank you! On Sun, Jan 11, 2015 at 9:57 PM, Scott Dowdle <dow...@montanalinux.org> wrote: > Greetings, > > ----- Original Message ----- >> And I checked my containers with 200% disk overuse from first message >> and got negative result. 24Gb of wasted space is not related with >> cluster size issue. > > Yeah, but 24GB is a long way off from your original claim (if I remember > correctly) of about 900GB... but those probably aren't comparing the same > things anyway. > > I'm lost... because ploop and zfs are not, so far as I can tell, competing > filesystems on the same level. zfs is competes with other filesystems like > ext4 or xfs... whereas for OpenVZ, so far as I know, there isn't a > disk-file-as-disk competitor. Given the popularity and stability of the > current qcow2 format popularized by KVM/qemu... and the large number of tools > compatible with qcow2 (see libguestfs)... I'm wondering if it would be > valuable to add qcow2 support to OpenVZ? > > You are currently using zfs with OpenVZ, correct? And you didn't have to > modify any of the OpenVZ tools in order to do so, correct? If that is the > case, what is it you want from the OpenVZ project with regards to zfs? > > So far as I'm concerned the license incompatiblity with the zfs/openzfs makes > it where it can not be distributed with stuff licensed under the GPL... so I > don't really see a way for OpenVZ to ever ship a zfs-enabled kernel... but > yeah, if needed they could add support for it in the tools if that makes > sense. I'm unclear on what you are looking for other than turning the OpenVZ > mailing list into a zfs advocacy group. > > I do however appreciate you metering wasted disk space by ploop as additional > data the OpenVZ devs can work with but as long as ploop isn't using more disk > space than the max size of the container disk, I don't really see a problem. > While it means one can't over-subscribe the physical disk as much... > excessive over-subscription is not ideal either... with wasted space acting > as a sort of pre-allocation buffer... and not actually wasted unless the > container's disk isn't going to grow in the future. > > I'd also like to see a comparison between ploop wasted space and that of > qcow2... although I'm not sure that qcow2 offers compaction features... since > I don't find the word compact in the qemu-img man page. Maybe there is a > separate tool for qcow2? > > TYL, > -- > Scott Dowdle > 704 Church Street > Belgrade, MT 59714 > (406)388-0827 [home] > (406)994-3931 [work] > _______________________________________________ > Users mailing list > Users@openvz.org > https://lists.openvz.org/mailman/listinfo/users -- Sincerely yours, Pavel Odintsov _______________________________________________ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users
