BTW, Pavel one issue which you or others might consider and test well before moving to ZFS: 2nd level (i.e. CT user) disk quotas. One will have to emulate Linux quota APIs and quota files for making this work. e.g. some apps like CPanel call quota tools directly and depending on OS installed in container these quota tools expect slightly different Linux quota behavior/APIs. In the past there was a lot of problems with that and we even emulated quota files via /proc. So be warned.
> On 11 Jan 2015, at 23:16, Pavel Odintsov <pavel.odint...@gmail.com> wrote: > > 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 _______________________________________________ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users
