LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 04-20-2015, 08:55 AM   #1
cwizardone
LQ Guru
 
Registered: Feb 2007
Distribution: Slackware64-current with "True Multilib."
Posts: 5,588
Blog Entries: 1

Rep: Reputation: 2995Reputation: 2995Reputation: 2995Reputation: 2995Reputation: 2995Reputation: 2995Reputation: 2995Reputation: 2995Reputation: 2995Reputation: 2995Reputation: 2995
ZFS: Myths and Misunderstandings (by Jesse Smith)


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:

Quote:
...Another common misunderstanding about ZFS is the idea that it cannot be legally shipped with Linux distributions due to licensing restrictions. This is not entirely correct. ZFS and the Linux kernel have licenses which are both open source, but not quite compatible. This means ZFS cannot be integrated into the Linux kernel, the source code of the two projects cannot be merged together and then distributed. However, there is nothing in either license preventing ZFS modules from being built for Linux and shipped with Linux distributions...

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

Quote:
...The other point was the announcement that Debian had been seeking legal advice regarding whether the project can include support for playing DVDs (via libdvdcss) and the ZFS advanced file system. The Software Freedom Law Center has given the go ahead for Debian to distribution both ZFS and libdvdcss packages and we should soon see these features appear in Debian's repositories...

Last edited by cwizardone; 04-20-2015 at 09:04 AM.
 
Old 04-20-2015, 09:18 AM   #2
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-Current
Posts: 6,449
Blog Entries: 15

Rep: Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021
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.
Old 04-20-2015, 09:33 AM   #3
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 6,962

Rep: Reputation: 4644Reputation: 4644Reputation: 4644Reputation: 4644Reputation: 4644Reputation: 4644Reputation: 4644Reputation: 4644Reputation: 4644Reputation: 4644Reputation: 4644
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.

Quote:
Originally Posted by cwizardone View Post
And another item of note that can be found further up the same page linked above,

Quote:
...The other point was the announcement that Debian had been seeking legal advice regarding whether the project can include support for playing DVDs (via libdvdcss) and the ZFS advanced file system. The Software Freedom Law Center has given the go ahead for Debian to distribution both ZFS and libdvdcss packages and we should soon see these features appear in Debian's repositories...
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).

Last edited by bassmadrigal; 04-20-2015 at 09:37 AM. Reason: Added additional quote and response
 
1 members found this post helpful.
Old 04-20-2015, 11:14 AM   #4
moesasji
Member
 
Registered: May 2008
Distribution: Slackware Current / 14.2
Posts: 305

Rep: Reputation: 98
Quote:
Originally Posted by bassmadrigal View Post
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.
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.
Old 04-20-2015, 11:19 AM   #5
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Germany
Distribution: Whatever fits the task best
Posts: 17,148
Blog Entries: 2

Rep: Reputation: 4866Reputation: 4866Reputation: 4866Reputation: 4866Reputation: 4866Reputation: 4866Reputation: 4866Reputation: 4866Reputation: 4866Reputation: 4866Reputation: 4866
Quote:
Originally Posted by bassmadrigal View Post
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).
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.
Old 04-20-2015, 12:22 PM   #6
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-Current
Posts: 6,449
Blog Entries: 15

Rep: Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021
Quote:
Originally Posted by moesasji View Post
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.
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.
Old 04-20-2015, 12:39 PM   #7
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 6,962

Rep: Reputation: 4644Reputation: 4644Reputation: 4644Reputation: 4644Reputation: 4644Reputation: 4644Reputation: 4644Reputation: 4644Reputation: 4644Reputation: 4644Reputation: 4644
Quote:
Originally Posted by moesasji View Post
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.
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.
Old 04-20-2015, 12:59 PM   #8
moesasji
Member
 
Registered: May 2008
Distribution: Slackware Current / 14.2
Posts: 305

Rep: Reputation: 98
Quote:
Originally Posted by ReaperX7 View Post
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.
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.
Old 04-20-2015, 08:32 PM   #9
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-Current
Posts: 6,449
Blog Entries: 15

Rep: Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021
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.

Last edited by ReaperX7; 04-20-2015 at 10:52 PM.
 
1 members found this post helpful.
Old 04-21-2015, 01:32 AM   #10
moesasji
Member
 
Registered: May 2008
Distribution: Slackware Current / 14.2
Posts: 305

Rep: Reputation: 98
Quote:
Originally Posted by ReaperX7 View Post
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.
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.
Old 04-21-2015, 02:00 PM   #11
mlslk31
Member
 
Registered: Mar 2013
Location: Florida, USA
Distribution: Slackware, FreeBSD
Posts: 210

Rep: Reputation: 76
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.
Old 04-21-2015, 05:17 PM   #12
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-Current
Posts: 6,449
Blog Entries: 15

Rep: Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021Reputation: 2021
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.
 
Old 04-21-2015, 07:03 PM   #13
mlslk31
Member
 
Registered: Mar 2013
Location: Florida, USA
Distribution: Slackware, FreeBSD
Posts: 210

Rep: Reputation: 76
Quote:
Originally Posted by ReaperX7 View Post
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.
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.
 
Old 02-22-2016, 10:58 AM   #14
cwizardone
LQ Guru
 
Registered: Feb 2007
Distribution: Slackware64-current with "True Multilib."
Posts: 5,588

Original Poster
Blog Entries: 1

Rep: Reputation: 2995Reputation: 2995Reputation: 2995Reputation: 2995Reputation: 2995Reputation: 2995Reputation: 2995Reputation: 2995Reputation: 2995Reputation: 2995Reputation: 2995
Quote:
Originally Posted by TobiSGD View Post
Scientific Linux already announced that the new version will feature an extra repository that can be enabled to get ZFS on Linux.
Looks like Ubuntu and Antergos have jumped on the bandwagon,

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

Quote:
"The most notable change in Cnchi 0.14 is beta support for ZFS (in Automatic Installation Mode). It is now possible to install Antergos with ZFS as your chosen file system. You simply tell Cnchi which drive to use and it will take care of formatting the drive and configuring ZFS for you."

Last edited by cwizardone; 02-22-2016 at 11:02 AM.
 
Old 02-22-2016, 11:07 AM   #15
Emerson
LQ Guru
 
Registered: Nov 2004
Location: Saint Amant, Acadiana
Distribution: Gentoo ~arch
Posts: 6,317

Rep: Reputation: Disabled
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Article ZFS data integrity testing and more random ZFS thoughts. LXer Syndicated Linux News 0 05-15-2010 12:51 PM
mail misunderstandings /authentication/blocked outbound smtp kevinyeandel Linux - Newbie 0 01-30-2009 08:44 PM
LXer: Eight common misunderstandings about GPLv3 LXer Syndicated Linux News 0 05-11-2007 07:16 AM
LXer: 10 common misunderstandings about the GPL LXer Syndicated Linux News 0 08-29-2006 12:21 PM
ZFS Root / Boot into ZFS from a usb flash drive Kataku Solaris / OpenSolaris 1 07-15-2006 04:13 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 11:18 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration