ZFS On Linux - It's Alive! 281
lymeca writes "LinuxWorld reports that Sun Microsystem's ZFS filesystem has been converted from its incarnation in OpenSolaris to a module capable of running in the Linux user-space filsystem project, FUSE. Because of the license incompatibilities with the Linux kernel, it has not yet been integrated for distribution within the kernel itself. This project, called ZFS on FUSE, aims to enable GNU/Linux users to use ZFS as a process in userspace, bypassing the legal barrier inherent in having the filesystem coded into the Linux kernel itself. Booting from a ZFS partition has been confirmed to work. The performance currently clocks in at about half as fast as XFS, but with all the success the NTFS-3g project has had creating a high performance FUSE implementation of the NTFS filesystem, there's hope that performance tweaking could yield a practical elimination of barriers for GNU/Linux users to make use of all that ZFS has to offer."
Yet to be included? (Score:2, Informative)
Of course, this will all change if both Sun and Torvalds switch to GPL3...
Grub (Score:5, Informative)
Grub has supported ZFS booting for a while (forget which branch though).
Re:Why not in the kernel? (Score:3, Informative)
Re:Grub (Score:2, Informative)
Never mind ZFS (Score:3, Informative)
The $COMPANY network is loaded with Linux workstations and servers, all with their own lotsabyte drives -- and the only things those drives are used for is a tiny system image. Meanwhile the network is getting hammered.
I might not kill to get a several-hundred-gigabyte local network cache -- but don't tempt me.
Re:It's time for Sun (Score:1, Informative)
No "co-opting" necessary. Solaris is every bit as much a terget platform for Gnome as Linux is.
Re:Limitations of Linux (Score:2, Informative)
Re:Why not in the kernel? (Score:4, Informative)
I am pretty sure that kernel modules run at the kernel level and can access all the same structures that a driver compiled into the kernel can.
FUSE file systems run at the same privilege level as a user program does. In theory it is a slower but more robust system. If a FUSE file system crashes you can just restart the filesystem and remount the drive. If a kernel level file system crashes it can cause a kernel panic and bring down the entire system.
So the distinction between user-land and kernel drivers is anything but arbitrary.
Re:Never mind ZFS (Score:4, Informative)
The $COMPANY network is loaded with Linux workstations and servers, all with their own lotsabyte drives -- and the only things those drives are used for is a tiny system image. Meanwhile the network is getting hammered.
Are you asking for a network based filesystem like AFS [wikipedia.org]? Did I misunderstand your issue?
Cheesy Intro to ZFS Video (Score:5, Informative)
Re:It's time for Sun (Score:3, Informative)
Sun exists to make money for it's shareholders. If and when it becomes advantageous to their share price to release ZFS then they will do it.
They have already stepped up to the plate and released Star/OpenOffice, Java, and significant portions of Solaris. Each of those software products is a very significant level of magnitude of work. How about a little bit of appreciation for those several person-years worth of work?
To imply that Sun is playing licensing games is disingenuous, at best.
And if you want to call someone out on licensing then how about Linus himself. Why does he own the trademark Linux? Yes, he provides free sub-licensing terms, but those are Linus' terms.
Much as Linus has his limits, Sun has it own limits of what it is willing to give up.
When Linus decides to give up the Linux trademark freely then he can legitimately start complaining about Sun Microsystems.
Parts of ZFS already GPLv2'd (Score:5, Informative)
http://blogs.sun.com/darren/entry/zfs_under_gplv2
Re:Why not in the kernel? (Score:5, Informative)
The version of the GPL included with the Linux kernel states at the top:
Not sure how far back this clarification really goes, but I think it predates the GPLv2-only one, making it at least six years old.
Re:Why the big deal about booting from it? (Score:3, Informative)
Nothing per se, but AIUI ZFS allows you to specify how much (if any) redundancy you want, which with other filesystems requires setting up RAID separately which in turn adds complexity.
I suspect that most people that would run ZFS are the type of people that leave their machines up for months at a time. In that case, why the panic attacks over booting issues?
Generally speaking, the kind of system that you want to have up for months at a time is also the kind of system you want to come back up as quickly and painlessly as possible should something happen which causes/necessitates a reboot. That's one of the main reasons journalling was invented.
I'm excited about ZFS (in concept and theory) and I would love to give it a go. Finally a system that's up with the times.
Not sure about "up with the times". I have yet to see any convincing explanation of what amazing features ZFS offers which hasn't been in AIX's logical volume management system for years.
"The FSF guideline is" (Score:5, Informative)
Re:Why not in the kernel? (Score:3, Informative)
This is and was always one of the chief complaints about Windows as well, everything in the kernel so a malfunction can take the whole system down. Now the push to user-space makes everything more robust. Of course you also take a performance hit hence the slowness that is Vista.
Still, if ZFS under FUSE is half as fast as XFS in kernel-mode then you're not talking about an FS that is particularly slow, you would still gain the data protection from ZFS which in my mind at least is the whole point. It would work for a near-line type storage system where performance isn't as critical. When the speed gets up then it can move to online storage where it will utilize the lessons it learned from near-line storage giving it a track record which will make people more comfortable in adopting it.
Re:"The FSF guideline is" (Score:4, Informative)
OTOH, some respected kernel developers (e.g. Alan Cox) certainly have explicitly said they believe binary kernel modules must be GPL and that things like nvidia's drivers are probably infringing. Not exactly the same thing but it's enough that I'd still call this a grey area until it's tested.
Re:Grub (Score:3, Informative)
As for the maintainer for sysvinit, the lsm [cistron.nl] tells you that. Or you could go with the maintainers of your distribution.
Re:Never mind ZFS (Score:2, Informative)
"When you enable cachefs file system, the data read from the remote file system or CD-ROM is stored in a disk-based cache on the local system. Subsequent read requests to the same data are fulfilled by the local cache, which improves read performance."
Of course, a migration is not always an option, and I'm not sure if something like this available for Linux.
Re:Why the big deal about booting from it? (Score:3, Informative)
- Ability to detect & disk corruption. Say you get a bad block/corruption on the bus/bug in a driver; your lovely mirror now has 2 different sets of data. Under every other volume manager I'm aware of, you have to guess which one has the correct data and resync (generally the whole drive). ZFS will automatically detect the corruption, figure out which drive has the correct data (using a checksum) and resync the data to the "bad" disk.
- Filesystems grow & shrink on the fly with no intervention. You have a 100GB disk (mirrored of course...) with two filesystems on it, but due to workloads, data moves between them. During the day,
/data1 has 80GB, /data2 has 10GB. At night, /data1 shrinks to 40GB but /data2 expands to 50GB during the batch; ZFS will let this happen with no intervention. You can also, if you want, allocate a minfree and max size of a filesystem if you want more control. You can shrink filesystems as of AIX 5.2 or 5.3, but that's fairly new and you'd need to manage it manually.
- Snapshots. They've been in various other VMs (e.g. Veritas) or filesystems (UFS snapshots have been in Solaris since Solaris 8 IIRC) but I don't recall them in AIX.
As for booting ZFS, the fact you could shrink or grow root & var filesystems is something new - Certainly, Solaris does not support resizing the root filesystem on the fly, even with Veritas on your root disks. The only way to resize is a backup/restore cycle (booting from CD) or using something like Live Upgrade (build a new image on some spare disks, then boot into it).Re:Why is it called "128-bit"? (Score:1, Informative)
http://src.opensolaris.org/source/xref/onnv/onnv-
However, the ZPL (ZFS POSIX layer) and DMU (data management unit) currently use 64-bit object identifiers based largely on the fact that no 128-bit POSIX interfaces exist (open128, stat128, etc). This could be changed in the future without affecting the on-disk block pointers, but for the time being the maximum size of any filesystem is 2^64.
Re:Why not in the kernel? (Score:5, Informative)
relicensing Solaris as GPL is entirely unnecessary and doesn't help Sun or Solaris at all... the only people it helps is Linux, and that shouldn't be the primary concern of OpenSolaris.
If OpenSolaris happens to help Linux, great, but it shouldn't hurt itself & go out of it's way to do it
Re:But, doesn't Linus... (Score:4, Informative)
The Linux kernel, for better or for worse, is going to be stuck at GPLv2.
Re:Why not in the kernel? (Score:4, Informative)
Linus decided. He wrote specific terms into the modified version of the GPL he uses with Linux. He makes it very clear. Linux does NOT use the "standard GLP" it makes a few changes for example he removed the "and later versions" part.
Re:Never mind ZFS (Score:3, Informative)
Try the I'm Feeling Lucky search for 'linux cachefs'.
no C structures larger than 64-bits (Score:1, Informative)
It is 128-bit clean, the problem is that ANSI C does not provide an data types larger than 64-bits, so they can't actually write (portable) data structures any larger.
Once ANSI defines larger 'int's (96? 128?) then you can write code.
Sun could probably use some kind of bignum library if they wanted to, but since they have not hit 64-bit restrictions on volume sizes yet there's no rush at this moment. They're just planning ahead a decade [sun.com] so they won't have to switch to another FS in the future. UFS lasted for about twenty years and they're hoping ZFS will last just as long.
According to some basic math [sun.com] it would take as much energy to boil the earth's oceans to flip every bit on a 128-bit file system.
NBD (Score:3, Informative)
That's *way* overkill. Grub can read minimal ZFS - just have Grub pull off an initrd image from your '/' drive (ZFS), load it into RAM (it'll be ext2 or squashfs or something the kernel can handle) and include a zfs.ko module on the initrd. Load it into RAM, do a pivotroot onto your ZFS / drive, and continue along your merry way.
The 'you can't boot off of ZFS' canard is just a bit of hand-waving by the Sun-haters who are afraid of ZFS. We Sun-haters who like ZFS know how to hack around half-truths.
Re:Why not in the kernel? (Score:4, Informative)
Retroactively, AND claiming to cover code for which he is not the copyright holder. The notice at the top of the COPYING file in the kernel source code more-or-less amounts to his opinion---and if you do a little research (read: Groklaw), you'll find that Linus clearly isn't a lawyer and doesn't know what he's talking about when it comes to legal matters.
"Linus said so" is just not a valid argument about a legal matter, unless you're trying to defend yourself against a copyright infringement claim that he's making about code he holds the copyrights for.
Re:Ah, well then... (Score:3, Informative)
Re:kernel patch? (Score:4, Informative)
Why hide? Nothing in the CCDL or GPL licenses prevents you from publishing a CCDL patch to a GPL kernel. Publishing the patched kernel source or binary might run you into some problems, but I don't see anything preventing you from publishing the patch itself.
Please correct me if I'm wrong.
Re:Why not in the kernel? (Score:3, Informative)
No. First off, do not turn this into a continuation of the debate of which is more Free: copyleft licenses such as the GPL, or BSD-style "our code is SO free you can make it NON-free!". This specific situation is much simpler: Linux has been GPLv2 licensed for about 15 years now, and the GPL itself is much older than that. Sun created the CDDL in the 2000's (not sure which year exactly) and has thereby acheived deliberate license incompatability with Linux and the GPL. There are other non-copyleft licenses which are GPL-compatible that Sun could have chosen, but they didn't: not that there's anything inherently wrong with this of course, it's their decision. Also, the GPL is NOT "incompatible with anything other than itself" like you state, check this list [gnu.org] to find all the licenses that disprove this wildly inaccurate statement.
It is not inherently Right or Wrong to use the CDDL for ZFS or the rest of Solaris. Sun holds the copyright on that code, so Sun can choose to license those projects however they see fit. It is not your place to say what license is correct for Sun to use on their code. Perhaps to your dismay, Sun has been seriously considering GPLv3 for Solaris [eweek.com], much like they did with Java and the GPLv2. And for all your talk about Linux "pillaging" code from Sun, you conveniently forget that this was a main driving reason for Sun to license Java under the GPLv2: license compatibility with GNU/Linux for easy inclusion of Java technology in distributions to attract users and developers.
While the CDDL was originally based on the Mozilla Public License, it is not the same thing. Perhaps more importantly though, Firefox is tri-licensed under the MPL, LGPL, and yes, the GPL. I can get a copy of Firefox licensed under the GPL, so it's especially important not to mislead others into thinking that such a prominent Free Software project exclusively uses a non-copyleft license, the CDDL, which isn't even one of the three licenses Firefox uses in the first place! Oh, and Apache has its own license altogether, albeit a non-copyleft one, the Apache license [wikipedia.org].
Re:Why not in the kernel? (Score:5, Informative)
He has added a note clarifying that userland programs making system calls are not derivative works. That is clarifying his interpretation of the license. At the most, it adds an exemption, which is common practice.
The "and later versions" clause is not part of the GPL, it lies outside it. In effect, it makes the work automatically multiple licensed as and when new versions of the GPL comes out: so if you distribute something under GPL v2 with that clause, when v3 comes you it will become dual licensed under 2 and 3, when v 4 comes out it will be triple licensed etc. This allows people to redistribute under v2 or any later version, with or without the "and later versions" clause.
Re:Isn't that... (Score:3, Informative)
A patch is structured, and further, contains specific (nonrandom) information on how to transform an input file into a previously created output file. It is, by definition, derived from two input files.
Furthermore, you appear to believe that a derivative work must somehow have structure or purpose similar to that of the original work. If I take Stephen King's The Gunslinger novel and remove every other word, I have created a new work derived from his. The novel might be somewhat readable, and it might not be. However it is clearly derivative.
Taking this further becomes tricky. What if I remove two out of every three words? It's probably still clearly derivative. Three out of every four? Maybe. It eventually becomes difficult to prove that the work is derivative--however this does not apply to patch files, which are reversible by design.
Re:Why not in the kernel? (Score:4, Informative)
The GPL doesn't require that everything linked to it be GPL'd, it requires that any changes or derivative works be licensed under a license (any license) that adds no more restrictions than the GPL itself does.