[Users] Shortest guide about running OpenVZ containers on top of ZFS

[Pavel Snajdr]

Well, innovation isn't about matching features that someone else has
just for the sake of having them too, is it? :)

What lot of people are missing about ZFS is that it is a self-contained
project trying to solve real storage problems. It's not trying to be a
filesystem. It is a complete storage solution. It's like you'd take a
NetApp and plugged it into your kernel directly.

Example features of ZFS that BTRFS will never have due to this fact:

- ARC - a smart caching mechanism, with which we're able to deliver
almost 100% hitrate almost 100% of the time - something that isn't even
remotely imaginable with linux LRU dcache

- L2ARC - second level ARC enabling you to cache less used ARC entries
onto a SSD

- dedicated device for ZIL - synchronous writes are a real pain with any
CoW filesystem, ZFS solves this so elegantly that it even beats Ext4
there - you can have your sync writes sent to a fast SSD or a NVRAM
device. Thanks to this I don't even notice heavy MySQL instances on our
machines, until we run out of CPU power. The disks aren't the
show-stopper anymore

- NFS, SMB, iSCSI integration - people judging ZFS from the traditional
linux kernel perspective don't get why should it be a filesystem's job
to do these - like I said, ZFS is not trying to be a filesystem. It's
trying to be the last storage solution you'll ever need on your server.

Etc. I could go on about this a while :)

Regarding the licensing issues. Well. ZFS isn't trying to be the best
filesystem for Linux. As far as I can remember, nobody from the ZFS
world has ever had any ambitions to get it into Linux. Even if the
license would allow merging ZFS in the kernel, the reality of ZFS design
as a self-contained solution wouldn't probably be accepted as well in
the Linux community as it was in FreeBSD. They're two completely
different cultures.

As I've already mentioned FreeBSD, here comes the next advantage ZFS has
over anything that Linux provides - BTRFS included: you can take your
pool today and open it on another platform, be it Linux, FreeBSD or
Illumos. Work is being done to ensure these implementations don't drift
apart and stay compatible - it is know as the OpenZFS project.

Regarding the patent issues, the same essentially goes for BTRFS, the
main concern wouldn't be Oracle here, it would be NetApp. They hold
enough patents to kick anyone around, doesn't matter if it's OpenZFS or
BTRFS. Only with Oracle they seem to be okay, because of Sun's previous
dealings with NetApp in this regard.

However, these patent concerns doesn't seem to hold any ground, as you
can see Nexenta and Joyent both making reasonable enough success to
tickle NetApp's nerves (especially Nexenta since they're a direct
competitor of NetApp in some market segments), yet nobody is suing them.
This is even less of an issue for me as everything I operate is in
Europe, where software patents don't apply.

Now it looks like I'm actually the one who's on holy crusade for ZFS here :)

But it all started off with me being really, really disappointed with
Ext4 performance. With ZFS I can get 80-120 heavy LAMP stack containers
on a single node, whereas the disks would be long dead with Ext4 before
I would even reach a half of that.

I've played around with having separate ext4 partitions for every CT (it
was before ploop), I've tried Facebook Flashcache to catch the sync
writes and offload them onto a SSD, I think I have tried everything I
could and not much has really changed since then on the Linux storage
scene (2012).

There's BTRFS, which to a layman looks like it's almost in feature
parity with ZFS, but if you actually try to use it, then "WAT" comes out
of your mouth like every second word. It still needs a lot of work.

Whereas ZFS as been in the production for more than 8 years now. And it
still is in active development with lots of companies and individuals
trying to make it better - they have much better starting point as far
as the innovations go, because they act on their own playground and they
don't have to deal with politics of such a huge project like Linux
kernel is.

/snajpa

On 11/13/2014 06:24 PM, Scott Dowdle wrote:
> Not really.  That isn't to say that btrfs is done or that all of its features, especially those added much later in the development cycle, are stable.  So, I don't contend that btrfs is a suitable contender to zfs at the moment but it does have a few benefits that will eventually put it over the top... past zfs on Linux.  What are they?
> 
> 1) It's in the mainline kernel and will be available in all distros with sufficiently new enough kernels.
> 
> That's it.  That's all it needs.  Being part of mainline Linux means that it'll get better integration with system tools by the distros and hopefully OpenVZ at some point.  ZoL will never get that... unless of course a Linux distro built just for ZoL comes along.
> 
> Because of licensing issues, none of the major Linux distros will ever ship with ZoL pre-installed.  Sure you can add it yourself... and it does a fairly good job of rebuilding itself when the kernel changes... but the extra work to add it and keep it updated will make it always be adopted less than something that is built-in.  Kudos to the ZoL developers for creating such a solid product and making packages for many distros and making it as easy as possible to add.
> 
> For those not wanting all of the more advanced features btrfs is ready now... and as I stated, SUSE and Oracle have been shipping it for some time.  When Red Hat signs off on it, I think that'll raise its status a bit.  For those just using it for checksums and CoW, it offers those advantages now.
> 
> So far as a feature for feature comparison of zfs and btrfs there is probably a 95% feature overlap with btrfs having some features that zfs doesn't and vice versa.
> 
> Do I blame anyone for using zfs?  No.  It's great.  I just don't want to use it myself.  The good thing is that is is very unlikely that Oracle will ever sue over patent issues... because they were the early sponsor of btrfs when most of the work was being done so they only have themselves to blame.