Slashdot Mirror
Oracle Engineer Talks of ZFS File System Possibly Still Being Upstreamed On Linux (phoronix.com)
New submitter fstack writes: Senior software architect Mark Maybee who has been working at Oracle/Sun since '98 says maybe we "could" still see ZFS be a first-class upstream Linux file-system. He spoke at the annual OpenZFS Developer Summit about how Oracle's focus has shifted to the cloud and how they have reduced investment in Solaris. He admits that Linux rules the cloud. Among the Oracle engineer's hopes is that ZFS needs to become a "first class citizen in Linux," and to do so Oracle should port their ZFS code to Oracle Linux and then upstream the file-system to the Linux kernel, which would involve relicensing the ZFS code.
One nice thing about ZFS not being in upstream is that it is currently maintained and updated separate from the Linux kernel.
Now, it would be nice to relicense ZFS under GPL so that it can be included in the kernel. But this should wait until the port is a bit more mature. Right now development is very active on ZFS and we have new versions coming out every few weeks; having to coordinate this with kernel releases will complicate things.
All this said, relicensing ZFS would definitely help Oracle redeem themselves a bit. After mercilessly slaughtering Sun after acquiring them, they have a long way to go to get from the "evil" side back to the forces of good.
Some folks don't like the particular set of tradeoffs, but for a filesyste (as opposed to an object store, one of which I'm testing right now), it's a very good offering. I definitely want it on my Fedora dev laptop, along with a write cache on flash.
davecb@spamcop.net
I've been using ZFS in my FreeNAS (FreeBSD) file server for over two years now.
Mark Maybee [...] says maybe.
Yeah right.
Feels like a donkey trying to fist fuck a cat.
*cough*Java*cough*
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
ZFS wants to live in a fairly specific configuration. It wants a bunch of drives, a bunch of memory, and not much competition for system resources. It's really a NAS filesystem, which is why there are no recovery utilities for it. If your filesystem takes a dump, you're SOL, hope you have a backup.
You can run it on a single drive on a desktop machine, but you are incurring a bunch of overhead and not getting the benefits of a properly set up ZFS configuration.
My Other Computer Is A Data General Nova III.
Why bother storing data on servers when you can store it in the network itself?!
http://code.kryo.se/pingfs/
> The problem with ZFS on Linux is that some aspects of it are redundant with the kernel.
Probably ALL aspects of it. Linux already has a raid implementation in-kernel. It already has filesystems. It already has multiple volume managers, which handle whichever type of snapshots you prefer. It already has IO schedulers. ZFS, or rather something that looks just like it, can be implemented as a few configuration lines for pre-existing Linux components.
Because Linux normally lets you use your choice of file system on top of your choice of volume manager, on top of whichever RAID implementation you choose, with your choice of IO scheduling options, ZFS isn't exactly the best fit. ZFS mashes all those different things into one big blob. That's not really how Linux is designed.
That's the same issue as systemd - it may (or may not) be a good init system. It may or may not be a good logging system. It may possibly be a good DNS server (probably not). But it can't seem to decide wtf it is.
Are you doing Z+1? Or just striping with an L2ARC, which is nearly pointless? What's the areal density of the drives? 'Cause if you are using anything above 2TB the odds of getting uncorrectable errors on both drives becomes non-trivial.
At this point you are better off using XFS with a really good backup strategy.
My Other Computer Is A Data General Nova III.
I can't tell you how many times boot environments saved my bacon after a particularly hairy upgrade flopped. I would really like to see that added to Linux.
OpenZFS hasn't been static, and has become a very successful cross-platform effort, which may be considered the main ZFS branch at this point, and most of the developers have left Oracle anyway. The introduction of feature flags has enabled a number of native features to be developed in parallel and development is thriving, with a native zfs-crypto implementation awaiting integration, among other goodies.
The thought of ZFS in the mainline kernel is attractive, but how would it be done without fragmenting the community? If Oracle contributes ZFS as GPL-only, that would be worse than useless, as it would require a break from the larger ZFS community and leave everyone with incompatible pools. Even if Oracle were more willing to reconcile their poor behavior, it isn't clear how the licensing differences with OpenZFS could be resolved, though ideas are welcome.
One nice thing about ZFS not being in upstream is that it is currently maintained and updated separate from the Linux kernel.
Now, it would be nice to relicense ZFS under GPL so that it can be included in the kernel.
I think you are a bit confused. You are thinking of ZFS-on-Linux (ZoL) which takes its code from the OpenZFS project (OpenZFS also runs on Illumos/OpenSolaris, BSD, etc.). What the presenter was talking about was Oracle-ZFS, which currently is Oracle Solaris-only.
I played with zfs-fuse on KDE Neon a couple years ago after reading from its acolytes that it was "more advanced" and "better" than EXT4 or Btrfs. It wasn't. A lot of it is missing in the fuse rendition.
I switched to Btrfs. I have three 750Gb HD's in my laptop. I use one as a receiver of @ and @home backup snapshots. I've configured the other two as a 2 HD pool and then as a RAID1, and then back to a pool again. In 2 1/2 years of using Btrfs I've never had a single hiccup with it.
There are some excellent posts on the KubuntuForums.net website by Oshunluver which describe how to use Btrfs to install many different distros to a single Btrfs installation, and how to use Btrfs in general.
Running with Linux for over 20 years!
My guess is that an engineer is not authorized to make that decision. His comments sound like pure speculation.
Just as this article popped up I was assembling a JBOD array (twelve 4TB drives) for a new data center project, my first in quite a while. Also self funded so I don't have to defer to anyone in decisions.
When I started I did a bit of reading trying to decide what RAID hardware to get. To make a long story short once I read the architecture of ZFS and several somewhat-polemic-but-well-reasoned blog entries I decided that is what I wanted.
Only two months ago I had an aged Dell RAID array let me down. I have no idea what actually happened, but it appears some error crept in one of the drives and it got faithfully spread across the array and there was just no recovering it. If I didn't have good backups that would have been about 12 years of the company's IP up in smoke. I just thought I'd share.
So I ended up as a prime candidate (with new found distrust for hardware RAID) to be a new ZFS-as-my-main-storage user. I've just recently learned stuff that was well established five years ago and I can't understand why doesn't everybody do it this way.
Wow. snapshots? I can do routine low-cost snapshots? Data compression? Sane volume management? (I consider LVM to the the crazy aunt in the attic. Part of the family but ...) Old Solaris hands are probably rolling their eyes but this is like mana from heaven to me.
Given the plethora of benefits I am sure the incentive is high enough to keep ZFS on Linux going onward. ZFS root file system would be nice but I am more than willing to work around that now.
> Until mdadm and hardware RAID controllers allow you to issue a "read, but try to give a different result" operation you can't do this. (Said operation would attempt to use parity even on a healthy array in an attempt to give a different block content by pretending a disk is dead).
So until the late 1980s? That's called RAID scrubbing and I believe it was mentioned toward the end of the original RAID paper in 1987 or 1988. Certainly 10 years ago I had a "mdadm check" command in my crontab. I know this for sure because I still have a copy of my 2007 server image.
The "mdadm repair" command was also in use by then.
Cool "new feature" you've got there.
I'll respond to your other two gross misunderstandings about raid by replying to your other post.
> ZFS has checksums to figure out which is right. MDADM doesn't.
You have no idea how RAID works, do you? Neither through the mdadm UI or any other.
RAID level 2 uses Hamming error correction codes.
Levels 3 through 5 use checksums much like ZFS does. Level 6 uses two independent sets of checksums, so even if you lose half your checksums, you're still okay.
>. if there is an API to allow you to ask for data from a specific disk rather than letting the RAID driver pick one, I'm interested.
An API to read from sda? Uhm, it's called read(). You very simply read from sda or whichever drive rather than reading from md0. That's how you can boot from a RAID 1 partition without the BIOS or bootloader knowing anything about RAID - it just reads from any of the member disks.
He hopes that... but he has no decision power, i bet. Maybe he's on the next firing list.
This is Oracle that we're talking about, it's more likely they'll let you license ZFS for a couple thousand per month...
I apologize for the lack of a signature.
One nice thing about ZFS not being in upstream is that it is currently maintained and updated separate from the Linux kernel.
And that's actually a huge problem that makes it a major obstacle to its upstream adoption.
Mainly due to code duplication.
ZFS (and its competitor BTRFS) is peculiar, because it's not just a filesystem. It's a whole integrated stack that includes a filesystem layer on the top, but also a volume management and replication layer underneath (ZFS and BTRFS on their own a the equivalent of a full EXT4 + LVM + MDADM stack).
That is a necessity, due to some features in these : e.g. the checksuming going on in the filesystem layer is also useful to determine correct copies in case of bitrot in the replication layer.
But how this is handled is the big difference between ZFS and BTRFS.
ZFS on Linux just packs all the needed bits together with it.
It comes with its own volume management and replication code.
That is a duplicate of functionnality existing elsewhere in the kernel.
And duplication is always bad for maintenance.
BTRFS being developped on Linux tries to leverage as much as possible :
- the Zstd compression currently being introduced to BTRFS, uses the same routines as the Zstd compression being introduced into the kernel loader : both leverage the in-kernel compression facilities of the crypto modules
- the device mapper facilities are used by lvm, mdadm and dmraid but also by btrfs. There was a plan to develop code to support more than 2 parity blocks (more than RAID6), that would have been beneficial to both btrfs and mdadm.
That's why developers complain of boundaries/layers violation with ZFS but not about BTRFS.
ZFS comes with its own tangled mess of layers, BTRFS is just a wrapper around facilities already existing in-kernel.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
In contradistinction ZFS takes a holistic, unified approach:
* Volument Management <--> File Management <--> Block
{...}
ZFS works because it intentionally "Flattened the stack" -- Yes, this runs counter to the layered Unix approach
The problem is that ZFS implement this by rolling everything in the same "rampant layering violation" package.
It is one single "flattened stack".
On the other hand, BTRFS shares as much code as possible with in-kernel facilities (it leverages "device mapper" routines that are used also by lvm, mdadm, mdraid, etc. it leverages in-kernel compression routine that are also used by the kernel loader and the crypto module, etc.)
It's not as much a "rampant layering violation" as a wrapper against layer facilities already existing in kernel.
-- but sometimes that is NOT the best design decision.
So basically, the problem isn't the overall design, but that actual code re-use vs. re-write.
Meanwhile Oracle keeps flailing about with Btrfs.
Btrfs works. It's in kernel, It's a first class filesystem in opensuse, and its copy-on-write facilities are extensively used for versioning with snapper.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Please remind me not to let you administer my filesystems.
http://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-your-data/
https://forums.freenas.org/index.php?threads/ecc-vs-non-ecc-ram-and-zfs.15449/
https://arstechnica.com/civis/viewtopic.php?f=2&t=1235679&p=26303271#p26303271
https://www.csparks.com/ZFS%20Without%20Tears.html
Unfortunately, it's not quite there. Very close though.
https://antergos.com/wiki/miscellaneous/zfs-under-antergos/
Just ask SUSE:
Just ask SUSE:
Just learn to read the docs if you insist on having esoteric options turned.
In 2017, RAID56 are still marked incomplete.
Modern filesystem are a huge pile of diverse features, some are fully stable and used in production (e.g.: RAID0 and 1) other are still in development (e.g.: RAID56).
Complain that BTRFS is completely crap because RAID5/6 isn't fully functionnal and production ready, is like complaining that the venerable XFS is utter crap because its copy-on-write and snapshotting doesn't work yet.
(and BTW, in-band deduplication doesn't even exist yet in BTRFS. ZFS is supposed to have it, but is an ultra-massive performance killer from what I've heard)
(auto-defrag works, but is a write-perfomance killer. alternatives a no defrag at all, which is a read-performance killer. or using out-band defrag, which requires maintenance and kills snapshot correlation.
all these are problem which are specific to copy-on-write (ZFS, BTRFS) and log-structured (UDF, F2FS) filesystems)
(
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
How about these?
Friends don't let friends use BtrFS for OLTP.
A drive can correct for errors if a block is bad. Problem is, as areal densities increase, the odds of data changing randomly increases. This is mainly due to cosmic rays or other natural sources of radiation, but there can be other factors. The drive doesn't know anything about the data itself, it only knows if it can read a block or not, and that's really the way you want it. You want the drive to be structure and data agnostic. Otherwise you would need a specific drive for a specific file system, which would be a nightmare.
My Other Computer Is A Data General Nova III.
BTRFS is the future. ZFS is an incredible memory hog.