A very interesting and informative article on ZFS, by Jesse Smith.
The entire article can be found at,
http://distrowatch.com/weekly.php?issue=20150420#myth

One interesting paragraph:


And another item of note that can be found further up the same page linked above,

That still doesn't supercede the GPL license, but it does create a vast grey area where a source compiled kernel could be made distributable with ZFS and SPL module support included as external source packages.

To be honest, this is a good development because honestly, if GPL could ever get a special exemption clause just for ZFS and SPL modules, which are CDDL, it might serve the GPL well and end users. The Illumos developers who sponsored the OpenZFS initiative made it adamant that ZFS would be developed as fully open source software despite the fact it was forcibly CDDL licensed thanks in part to Oracle.

Maybe this can apply to Slackware as well somehow? Personally, if this could ever allow not just one, but any distribution to have binary built-in SPL and ZFS support, I'd go straight over to ZFS, no questions asked if it was included on the install disk menus.

1 members found this post helpful.

Thanks for this. I had read a lot about the recommended use of ECC memory and to have 1GB of RAM per 1TB of storage on the /r/DataHoarder subreddit and it was turning me off of considering zfs in a future build for a storage server. It's good to know those are just myths.

It's also good to know the reason why zfs isn't included in the kernel. If I had done research, I would've likely found it was incompatible licenses, but I just assumed the port wasn't stable enough for inclusion.

I wonder if this will lead to more distributions, including Slackware, to include libdvdcss (not that it matters to me since I don't play dvds in my computer anymore).

1 members found this post helpful.

I've used both ZFS and btrfs on the same hardware and am far more pleased with btrfs. Anyway biggest problem with ZFS for home machines is that you can only grow a pool, but never shrink it in contrast to BTRFS. For ZFS this is probably no problem for enterprise usage, but not for home machines with only a limited budget and limited amount on SATA ports as it makes it much harder to replace disks for example in a raid1 setup.

btw) Overall btrfs in my experience runs smoother on Slackware. A scrub with ZFS of non-system disks had a noticable impact on how responsive the system was; btrfs just churns along leaving the system responsive and in fact finishes far faster (=higher data-throughput); not sure why.

3 members found this post helpful.

Scientific Linux already announced that the new version will feature an extra repository that can be enabled to get ZFS on Linux.

1 members found this post helpful.

ZFS was developed to make sure maintenance was done offline rather than online due to the fact scrubs take time to complete and data checks need to be consistent before the disk is brought back online. Even if btrfs has all these features, I still trust ZFS more. It's been around longer, and even if it has less features, it's built that way for a very good reason.

1 members found this post helpful.

Those were two that I was considering (well, until I saw the myths about ZFS). I'd like to say this project is just around the corner, but due to an impending bathroom remodel and extensive re-landscaping, it could be over a year before I actually get the ok from the wife to do it (right now, I'll just replace lower capacity drives with higher capacity ones in my desktop/server as I have been for years). It'll be interesting to see the advances for both filesystems by the time I actually get to it. If I go with one of the two, it'll like be btrfs, but I'm still keeping my options open.

1 members found this post helpful.

A scrub is a check that data on disk is consistent; so I would find it very hard to believe that this should be done offline in particular because ZFS under FreeBSD didn't suffer from this. Anyway I would have liked to keep zfs for the same reason you state.

What made me switch was the problem of not being able to shrink pools making it hard to upgrade a raid1 array on a typical home-computer; that in my opinion is the key drawback of zfs, which isn't obvious until you hit it.

1 members found this post helpful.

True, but then again, I tend to use zvols under my own defined quotas and limit my usages down similar to how you stack partitions. This way I never have to worry about shrinkage, and I can allocate resources more effectively.

Even with FreeBSD you still have some offline maintenance features not accessible while in the online state, which is why they have a recovery partition embedded in the OS. This way you can boot to the recovery mode, access the shell in a RAMdrive and then scrub the zvol while it's in the offline state. Plus, with the scrub active you shouldn't be doing tasks anyway. Normally my longest scrub times are less than 30 minutes with my largest disk arrays so I'm used to using the recovery mode.

One of the reasons you can't shrink a volume with zfs is because of data allocation on the disk itself and the metadata and metadata addressing that serves as the shadow copy for write backs and data recovery. BtrFS does their journaling and metadata addressing using B-trees which operate differently from how ZFS works entirely. It's the same principles, but ZFS uses a completely different tree structure that doesn't allow for shadow copy write back data to be moved around so that if there is a problem with data scans, it can write back from the shadow copies to the proper disk addressing space.

Overall, the trade offs are minimal between each, but when it comes to know what does what, ZFS still beats BtrFS hands down. It doesn't have all the nice features, but then again, does it really need them?

In the end, I think it would be good for any distribution to have ready to use modules on the installation disk, and tools to allow usage of ZFS, provided we, the end user, have control over building the Linux kernel and choosing whether or not to have our kernel with ZFS as built-in or modularized.

1 members found this post helpful.

I fully agree that having the option to use zfs under linux is a fantastic thing and it should definitely be made easier as bitrot is a serious problem on large disks and moreover the commands of zfs are more logical.

The only thing to keep in mind is that as with every choice it has pros and cons, so it is important to make both of these clear. To me it appears that you run zfs on relatively small arrays as you can finish a scrub in less than 30 minutes. I'm running it on large arrays, currently 6 disks totaling 22TB of space set up in raid1 on a consumer desktop now using btrfs. For that type of usage the lack of the ability to both shrink a pool as well as the lack of the option to rebalance after putting a new bigger disks in became a problem for me as swapping out disks becomes not funny in zfs, while it is easier to do in btrfs. Keep in mind that once you hit a disk nearly full situation in an array the write performance drops through the floor. I can fix that in btrfs, not in zfs without resorting to tricks to force rewriting data. So for my usage pattern at the moment btrfs is the only realistic option until zfs implements the long requested block pointer rewrite.

1 members found this post helpful.

It would be better if you chucked the article and played with ZFS for several weeks, preferably alongside btrfs.

The article simply tried too hard to dispel myths, and so the article became suspect. The attempts at proof were over the top. The easy dismissal of licensing issues becomes not so easy when trying to run a kernel with a lot of debug features, or when trying to make a classic kernel that can boot with an in-kernel file system driver to a / partition formatted with that file system, all without the assistance of an initrd.

ZFS can run on mortal hardware in non-enterprise workloads. This particular 64-bit FreeBSD PC uses ZFS-on-geli mirrors while using 3 GB (once 2 GB) of RAM. That hasn't been an out-of-memory issue in 2 GB of RAM, haven't tried less for 64-bit PCs. The PC does not use ECC RAM. All has been fine. That's good anecdotal proof. But to mislead people into thinking that ZFS isn't absolutely miserable when starved for memory, no, that isn't good. ZFS tends to bring Linux to a crawl in too little memory and cause FreeBSD to trap. By comparison, btrfs will boot on a minimal 32-bit system using less than 32 MB of memory and will cruise under similar workloads. It's not a show-stopper: If ZFS kills your PC due to memory starvation, add more memory! If it's a small desktop workload, that more memory shouldn't need to bring the total to 8 GB. Some of the higher memory quotes involve deduplication as well: If you use deduplication, maybe you should heed those quotes. I'm not that bright: I simply run ZFS without deduplication until FreeBSD runs out of memory, and it's a cue to buy more memory. So far, the upgrade to 3 GB has been optional.

There are misconceptions about ZFS, sure, but the article might not have been the best way to address those misconceptions.

1 members found this post helpful.

There's also a memory buffer command you can add during boot sequences (mostly for FreeBSD) that will work if you have less than 4GB of RAM to allow ZFS usages.

4+GB is rather commonplace these days though for many systems, and if you run a 64-bit OS, you should be using 4+GB of RAM anyways.

I've never had ZFS lockup or slow down myself on Linux or BSD with any system, including my old 2GB RAM laptop I run OpenIndiana on.

There's many misconceptions about ZFS, but yes the license issue is still the biggest part of the problem, however, if the SFLC who say a distribution can use ZFS internally legally without repercussions legally, then the license issue is moot. If the SFLC found a legal loophole in GPLv2 and CDDL, then by all means, they found one nobody knew of or about.

I started with ZFS on an i686 Pentium 4 with 384 MB of RAM, so I've hit some situations that make me wary. You might be OK on what passes for ordinary hardware these days. I've seen ZFS not keep up with a PC-BSD install on early 64-bit hardware. Though I blamed ZFS--that was what dominated the stack trace--I also questioned the heaviness of that pretty PC-BSD desktop that I wanted to try. Since then, I've retreated to my Xfce safe hiding place, praised FreeBSD for being good with ZFS on aging junk.

Looks like Ubuntu and Antergos have jumped on the bandwagon,

http://distrowatch.com/weekly.php?issue=20160222#news

I had kernel crashes with 4 GB of RAM, RAIDZ2 4 TB usable. It crashed every time when load went up. Upgraded to 16 GB ECC RAM, never had a crash after that.