[Users] OpenVZ and ZFS excellent experience

[Pavel Odintsov]

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 <dowdle at 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 at openvz.org
> https://lists.openvz.org/mailman/listinfo/users



-- 
Sincerely yours, Pavel Odintsov