Sun and Oracle, a tale of two filesystems

It was just a matter of time before something had to happen with Sun. When the IBM deal fell through it wasn't clear to me who else would be interested. What I was missing was Oracle's desire to move into hardware. Since Oracle has decided they want to be in that business the Sun purchase is quite a coup for them.

I am a software guy, so their software is what interests me. Well, some of their software. According to the released statements Oracle considers Java the most important software acquisition they have ever made. That is probably an accurate assessment, but one I am totally uninterested in. They also mentioned Solaris and storage products, but they did not drill down into those.

Oracle didn't own an OS. They used Linux extensively, but now they control Solaris. They will be supporting both going forward. There might be some value to owning the copyright on an opensource OS as opposed to simply making your own distribution, but I am not convinced. What interests me more are the implications for the future of Unix filesystems.

ZFS

When Sun released ZFS it caught a lot of people's attention. The thing that might surprise a lot of fanboys is that some of it was not entirely positive. With ZFS Sun rethought the traditional storage stack, and in the process they completely relayered it, but ZFS was the only consumer. So from the outside it looks like a huge monolithic entity that is "rampant layering violation," despite the fact that is in essence a complete parallel stack that can have its various components used by multiple consumers, just not necessarily in the same way the current stack is used.

The next version of Lustre uses the ZFS DMU directly for its storage, allowing it to use most of the ZFS stack but bypass the actual posix filesystem interface. In essence it can be thought of using the block allocation, checksumming, and snapshotting infrastructure while supplying their own name lookup and API.

Despite all of that, ZFS had so many obvious benefits that a number of people ported it (including its entire parallel stack) to various platforms. I don't know that I would run a critical storage application on it yet, but that is purely an issue of code maturity and testing of what is a disruptive and novel technology. Their design is fundamentally very sound.

The elephant in the room was Linux. Linux is released under the GPLv2, and Solaris under the CDDL. That meant it was legally impossible to integrate the two as a single product.

Btrfs

Now the benefits of ZFS are obvious, and traditionally the Linux guys have no quibbles with integrating well though out, well designed technologies that are a bit immature. Since they couldn't implement ZFS, it was only a matter of time before someone decided to clone it. Btrfs (pronounced "Butter FS") is conceptually very similiar to ZFS. It has some new novelties and some improvements. It should, it is being done years later and people can examine ZFS to understand the implications of various decisions.

While Btrfs is conceptually similiar to ZFS, there is a major difference. It doesn't completely turn the entire Linux storage stack on its head, at least not suddenly. While Sun had a couple of filesystems to support on Solaris, it was relatively simple for them to decide ZFS was their future and give it this entire parallel infrastructure. Linux has dozens of filesystems, and introducing such radical changes for a single filesystem sets a dangerous precedent. Linus might let it happen if he can be convinced the code is well thought out and it brings worthwhile improvements, but that is no way guaranteed, as evidenced by the fiasco that was Reiser4.

Since the Btrfs guys are designing it from scratch on Linux anyway, they have decided to extend the existing layers of the Linux kernel to support the semantics they need. Rather than have btrfs completely implement its own drive management and storage pool interface as ZFS did, they intend to extend the existing Linux Device Mapper where possible in order to provide the interfaces they need. In essence the are attempting to morph the existing Linux stack into something that can operate very similiar to the ZFS stack.

Sun and Oracle

Now the interesting thing here is that while Sun owns ZFS, the primary development of Btrfs is being funded by Oracle, with several other companies providing considerable resources. This means that Oracle owns two conceptually very similiar FSes. ZFS is more mature, is actually in deployment, and runs on Solaris. Btrfs is newer, designed in a way that integrates more cleanly with Linux, but is 1-2 years away from early adopter usage.

I am sure some people are convinced Oracle will kill Btrfs and port ZFS to Linux. I'm not so sure about that, but what is clear to me is that they will either need to port Btrfs to Solaris or ZFS to Linux, since having the two operating systems only support incompatible filesystems when you are trying to sell enormous storage systems that are impractical to migrate is a horrible story to tell to your customers.

The honest truth is that I doubt they have figured out their exact strategy with filesystems yet, they put this deal together in two weeks, and even though ZFS and Btrfs are what I am most interested in I doubt they warranted much attention compared to Java.

Comments

[Drew Thaler]

Btrfs is mildly interesting, but its major drawback is the GPL.

GPL kernel code is poisonous to Microsoft, Apple, Sony, etc. That suggests to me that Btrfs will be stuck as a sandbox project and won't gain any momentum until and unless somebody reimplements it under BSD.

If ZFS stays out of GPL then it could get gain wider (non-Linux) adoption. I don't know that it's actually right for a x-platform data exchange standard, but that's a different discussion.

[Louis Gerbarg]

At a practical level anything in the Linux kernel is GPLv2, which means unless people want to do multiple implementations against a single volume format people have to find a way to cope with that. While you could just drop in code with some other licenses (BSD) in to the Linux kernel, in practice the Linux guys just multi-license different bits of the kernel, so I would expect Oracle to dual-license any Solaris code they want to share as CDDL/GPL..

Dual licensing is actually really weird, since it is possible to put things under two contradictory licenses. The users of the code gets to choose which license they actually want to use the code under. Theoretically they can contribute back code under only one of the licenses if they want to be a pain in the ass, but because of Linus' personal sense of morals it all tends to work out in Linux. While I might be hesitant to base huge business decisions on single person I have no influence over, anyone dependent on Linux has already decided to entrust quite a bit to Linus' judgement anyway.

Specifically, I believe Linus feels that people have the right to license code they have written the way they want to. Even if the license code is under just the code to be subsumed into a GPLv2 project he prefers to get their permission before changing it to GPLv2 or to keep the additional license intact as well. He said as much in a post to LKML a few years ago discussing the GPLv2 only "clarification" to the kernel, but I am having trouble finding that post at this moment.