Hello, all! Thank you for feedback!
Kirill, you are absolutely right and this issue mentioned in my comparison table https://github.com/pavel-odintsov/OpenVZ_ZFS/blob/master/OpenVZ_containers_on_zfs_filesystem.md But there are some progress at this field there https://github.com/zfsonlinux/zfs/issues/2922 and there https://github.com/zfsonlinux/zfs/pull/2577 This issue can be solved with using ZVOL's instead ZFS native volumes. There are my manual about this: https://github.com/pavel-odintsov/OpenVZ_ZFS/raw/master/openvz_and_zfs_zvol_ext4.pdf (sorry, it's only in russian but you feel free to use Google Translate :). On Mon, Jan 12, 2015 at 8:55 AM, Kirill Korotaev <d...@parallels.com> wrote: > 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 -- Sincerely yours, Pavel Odintsov _______________________________________________ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users
