I have a question that has been puzzling me for some time ... what is the reason RedHat chose to go with btrfs rather than working with the ZFS-on-Linux folks (now OpenZFS)? Is it a licensing issue, political, etc? Although btrfs is making progress, ZFS is far more mature, has a few more stable features (especially Raid-z3) and has worked flawlessly for me on CentOS-6 and Scientific Linux-6. I used ZFS for a couple of large file servers with no problems. The only annoying part was having to manually install the kernel module each time a kernel update was issued. Because FreeBSD has built-in drivers for LSI cards (I use JBOD mode) and strong ZFS support, I've switched to FreeNAS with it's default native ZFS and driver support for LSI. I would have preferred to stick with CentOS, but FreeNAS just made things easier to manage. It also seems about twice as fast as ZFS on Linux (same hardware), but that may simply be a tuning issue. Is there any chance that a native ZFS (rather than btrfs) will ever emerge in RHEL/CentOS? Just curious, because I'd love to return to CentOS/SL next time I build large file servers. As an aside, I have used only WD Black and WD RedPro drives for RAID, and not had any issues. Green drives are scary :-) Chuck
On Fri, May 29, 2015 at 07:51:58AM -0700, Chuck Munro wrote:> I have a question that has been puzzling me for some time ... what > is the reason RedHat chose to go with btrfs rather than working with > the ZFS-on-Linux folks (now OpenZFS)? Is it a licensing issue, > political, etc? > > Although btrfs is making progress, ZFS is far more mature, has a few > more stable features (especially Raid-z3) and has worked flawlessly > for me on CentOS-6 and Scientific Linux-6. I used ZFS for a couple > of large file servers with no problems. The only annoying part was > having to manually install the kernel module each time a kernel > update was issued. > > Because FreeBSD has built-in drivers for LSI cards (I use JBOD mode) > and strong ZFS support, I've switched to FreeNAS with it's default > native ZFS and driver support for LSI. I would have preferred to > stick with CentOS, but FreeNAS just made things easier to manage. > It also seems about twice as fast as ZFS on Linux (same hardware), > but that may simply be a tuning issue. > > Is there any chance that a native ZFS (rather than btrfs) will ever > emerge in RHEL/CentOS? Just curious, because I'd love to return to > CentOS/SL next time I build large file servers. > > As an aside, I have used only WD Black and WD RedPro drives for > RAID, and not had any issues. Green drives are scary :-) > > ChuckLicensing, IMO. Redistributing ZoL is likely fraught with a bit of legal peril, or at best, technical peril if you want to try and skirt the legal edges. Oracle is notoriously litigious and having a target liked Red Hat would probably have their lawyers whetting their chops. Ironically, btrfs was also an Oracle thing -- in that Chris Mason worked for them (believe he's now at Google?). Do agree that ZFS feels like what btrfs is trying to become. I use ZoL on some production boxes and its been quite stable, but am also considering the approach you've taken with FreeNAS for some larger deployments to chase after a bit more performance and tighter integration with the OS... Ray
Chuck Munro wrote: <snip>> As an aside, I have used only WD Black and WD RedPro drives for RAID, > and not had any issues. Green drives are scary :-)It's the TLER that kills you. We tried some early 3TB greens in some of our Penguins (OEM, rebranded Supermicro), and within a month, they'd start giving DRDY errors. It turns out that there were two issues: 1. They keep trying to spin down; ok in desktops, bad, bad, bad on servers. And this is *not* RAID, just as a plain vanilla drive. 2. Around '09, led by WD, they changed the firmware. Previously, you could use hdparm to set the TLER; after then, it was not user settable. TLER: if the drive finds a bad sector, this is how long it will retry before giving up, and rewriting it to another sector, marking that bad. The greens try for up to two ->minutes<-; servers' firmware expects this to happen in < 7 ->seconds<-. System is *not* happy.... mark
Once upon a time, Chuck Munro <chuckm at seafoam.net> said:> I have a question that has been puzzling me for some time ... what > is the reason RedHat chose to go with btrfs rather than working with > the ZFS-on-Linux folks (now OpenZFS)? Is it a licensing issue, > political, etc?Licensing. Sun chose an Open Source license that is incompatible with the GPLv2 as used by the Linux kernel, so it is not legally possible to distribute a combined work of the kernel and the Sun ZFS code (at least that's the opinion of a number of lawyers, including Red Hat's; not all agree, but not worth arguing about here). It is possible to access ZFS filesystems through the FUSE layer using Sun-derived code (because that doesn't create a combined work), but that's not really an "enterprise" filesystem access method. The only legal way to use ZFS natively under Linux would be to not use any of the Sun code and reimplement ZFS from scratch for Linux. That would be a large job. BTRFS also is much better integrated with the Linux kernel's way of doing things. The Linux ZFS port keeps its own cache separate from the kernel's page cache, which complicates memory management. Also, BTRFS has features that ZFS does not. I expect BTRFS to get a lot more mature in the near future, as Facebook is putting resources into moving parts of their infrastructure to BTRFS. -- Chris Adams <linux at cmadams.net>
Chuck Munro <chuckm at seafoam.net> wrote:> I have a question that has been puzzling me for some time ... what is > the reason RedHat chose to go with btrfs rather than working with the > ZFS-on-Linux folks (now OpenZFS)? Is it a licensing issue, political, etc?There is no licensing issue, but there are OpenSource enemies that spread a fairy tale about an alleged licensing issue. The only problem with integrating ZFS into Linux is that the VFS interface from Linux is inferior to the one from OpenSolaris and as a result, there is a need to first implement missing interfaces. J?rg -- EMail:joerg at schily.net (home) J?rg Schilling D-13353 Berlin joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'
Ray Van Dolson <rayvd at bludgeon.org> wrote:> Licensing, IMO. Redistributing ZoL is likely fraught with a bit of > legal peril, or at best, technical peril if you want to try and skirt > the legal edges. Oracle is notoriously litigious and having a target > liked Red Hat would probably have their lawyers whetting their chops.Please avoid unverified insinuations like this one. J?rg -- EMail:joerg at schily.net (home) J?rg Schilling D-13353 Berlin joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'
Chris Adams <linux at cmadams.net> wrote:> Once upon a time, Chuck Munro <chuckm at seafoam.net> said: > > I have a question that has been puzzling me for some time ... what > > is the reason RedHat chose to go with btrfs rather than working with > > the ZFS-on-Linux folks (now OpenZFS)? Is it a licensing issue, > > political, etc? > > Licensing. Sun chose an Open Source license that is incompatible with > the GPLv2 as used by the Linux kernel, so it is not legally possible toThis is an infamous insinuation that has been verified as being false by the prople who know better (e.g. Simon Phipps). Correct is: - The Sun developers had threatened to leave Sun in case Sun would use the BSD license for OpenSolaris. So BSD was not possible. - The GPL is not free enough to make it usable for OpenSolaris. So the GPL was not possible. - The license chosen (the CDDL) gives maximum compatibility to other licenses. BTW: I have been involved in the discussions for the license selection and I can verify as well that you are the victim of a fairy tale.> distribute a combined work of the kernel and the Sun ZFS code (at least > that's the opinion of a number of lawyers, including Red Hat's; not allName us a single credible lawyer that made this claim..... In contrary, well-known lawyers (e.g. the lawyers of Harald Welte) explained why a combination of a filesystem with the Linux kernel is not problem.> The only legal way to use ZFS natively under Linux would be to not use > any of the Sun code and reimplement ZFS from scratch for Linux. That > would be a large job.With this funny claim, you just again verify that you are uninformed. If you reimplement the code (even though there is no legal need to do so) you _create_ a legal problem as only the original code includes the patent grant from the CDDL. If you reimplement the code, you need to pay royalities for the patents. If you like to use legal free code, you _need_ to use the original implementation. J?rg -- EMail:joerg at schily.net (home) J?rg Schilling D-13353 Berlin joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'
On 06/01/2015 06:42 AM, Joerg Schilling wrote:> Chuck Munro <chuckm at seafoam.net> wrote: > >> I have a question that has been puzzling me for some time ... what is >> the reason RedHat chose to go with btrfs rather than working with the >> ZFS-on-Linux folks (now OpenZFS)? Is it a licensing issue, political, etc? > > There is no licensing issue, but there are OpenSource enemies that spread a > fairy tale about an alleged licensing issue. > > The only problem with integrating ZFS into Linux is that the VFS interface from > Linux is inferior to the one from OpenSolaris and as a result, there is a need > to first implement missing interfaces. > > J?rg >Guys ... let's try not to have a license fight again on the list. Sometimes these things get way out of hand. This list is not a place for legal advise .. let's let the attorneys who actually know the law and the maintainers of programs decide what license they use and what it means. Whatever is in RHEL sources, that is what will be in official CentOS Linux .. and if you want something else (ie, ZFS) .. then get like minded people and start a SIG to maintain that for CentOS on the CentOS-devel mailing list. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20150601/1cc82049/attachment-0001.sig>