Submitted by “Remember KQ Infotech? KQ Infotech was the Indian company that ported the ZFS file-system to Linux as an out-of-tree kernel module (after deriving the code from the LLNL ZFS Linux work) and KQ’s interesting methods of engagement in our forums. The company was successful in delivering an open-source ZFS module for Linux that performed semi-well and didn’t depend upon FUSE (the file-systems for user-space module) like other implementations. However, this ZFS Linux code appears to no longer be worked on by KQ Infotech.”
With btrfs now becoming the standard filesystem for FEDORA (see: http://www.osnews.com/story/24839/Fedora_16_To_Use_Btrfs_by_Default), this is a signal that probably with Redhat Enterprise 7 at the latest, and there are signs that maybe even during the current RHEL6 life cycle, BTRFS will become the standard enterprise filesystem.
btrfs, has been a feature preview in RHEL(since 5.3 if I remember) and its now fully baked into RHEL6 for full blown testing as a primary filesystem and a fair number of people have been using it and giving feedback and helping it to mature at a pretty good pace.
Once btrfs is stable and in mainstream use, there will be zero need for ZFS in the linux world, it will pretty much have feature parity.
Edited 2011-06-15 15:35 UTC
You’re *almost* correct. Having the ability to read ZFS volumes is still a useful thing to have in if you happen to be running a mixed shop or are migrating from Solaris to Linux based systems. Niche yes, yet still very useful if you fall into the niche.
I’m also skeptical about RHEL migrating to BTRFS as a recommended filesystem quite so quickly. At the moment the performance just is not there for the sort of tasks that the enterprise needs. It may very well be a fully supported option, but I seriously doubt it’ll take center stage before well into RHEL 7
Edited 2011-06-15 18:38 UTC
I think if you need to copy some data, maybe the FUSE version would be enough.
It’s going to a long while, probably beyond RHEL 7, before btrfs reaches feature parity with the current version (ZFSv28) of open-source ZFS. Missing pieces are:
* working fsck and other recovery tools
* single, dual, triple parity (RAID5/6/+) support
* deduplication support
* encryption support
* probably more
Other than the first item, none of the above are even being worked on.
btrfs is a nifty filesystem, but it’s no ZFS, and won’t be for many years yet.
Why would you need fsck, ZFS didn’t need it 😉
There is definitely an interrest in deduplication, I think there is also working code. So I wouldn’t be surprised if atleast offline support will be available.
Edited 2011-06-16 09:32 UTC
Personally I found the tooling of btrfs terrible to use compared to zfs. So only in that sense it’s still miles behind zfs.
Also zfs’s send and receive are also missing.
Don’t get me wrong I love the btrfs effort and I’ll probably switch to btrfs instead of zfs. (as you still need to run solaris for any serious use, or deal with the ancient fbsd version)
But I hope that by that time the tools will be a lot more friendly to use then there now.
Besides all the technical features, this is one of the major benefits of zfs imho.
ZFS is still superior to BTRFS, so having a native ZFS support is very useful.
This may be a bad move for Linux. A filesystem is much more important than a kernel to be really stable. If a kernel is unstable and crashes, you might loose a couple of hours of work. If a filesystem crashes, you might loose several years of work.
A filesystem have much higher standards than a kernel. It takes years and years to accept a filesystem as production ready. Many Enterprise companies will wait a decade. Even ZFS, mature as it is, has it’s bugs today. BTRFS will have even more, and much functionality is not even developed yet. I dont even know how many developers are working on BTRFS. Oracle bets big money on ZFS (which they earn money on) and has not reallocated many devs to BTRFS – as I have heard of. Oracle thinks ZFS is superior, and it earns money. Today.
Not good when Linux use unstable and beta code and call it production ready. Even Linux kernel developers confirm this lead to low code quality. Linux developer Andrew Morton says the “linux code quality is declining”. This might be a bad move for Linux, when reports of people loosing data drops in. Read the BTRFS mail lists and forums, lots of problems and bugs there is.
A triumph for NIH.
Not really. It’s more like a failure of the “let’s be incompatible with the GPL on purpose, while using a license that is exaclty like the GPL”.
http://zfsonlinux.org
Produced at Lawrence Livermore National Laboratory
Luck for us we do have OpenIndiana, BSD’s and Debian with a BSD kernel for those advanced enough to understand how great ZFS really is.
Unfortunately, those advanced enough also understand how behind those ZFS versions are from the “official” Solaris ZFS.
(and I am using an all-ZFS FreeBSD server…)
FreeBSD has recently caught up significantly, with v28 now in STABLE – which means the next release of FreeBSD will only be a couple of versions behind Solaris.
Edited 2011-06-16 07:21 UTC
The real question is: will it get any updates after that ?
As Oracle is now keeping things a lot more closed.
Even if they don’t, ZFS will still far exceed anything else available for a long time to come.
The only thing that even comes close is BtrFS and, as already discussed, that’s not even at the same point as ZFS v14 (as included with FreeBSD 8.1 RELEASE).
In fact there’s still debates as to whether BtrFS is even ready for production use.
Given the infrequency of the average file system upgrade cycle, I’ll quite happily stick with ZFS (even in it’s v14 incarnation – let alone v28+) for a good few years yet before I consider switching my storage arrays.
Edited 2011-06-16 09:58 UTC
I do agree that ZFS v14 is now pretty much feature complete.
But before that, deduplication, l2arc (second level cache) and so on where things people really wanted after seeing them in ZFS/Solaris.
So if Oracle decided to add something cool or improve performance by a great deal others might not get that code.
We’ll have to wait and see what happens with the official release of Solaris 11. They’ve “promised” to release the code for all things CDDL once the actual Solaris 11 release has been made. When that is scheduled to happen is anyone’s guess.
In the meantime, the ZFS Working Group (made up of devs from FreeBSD, Illumos, Nexenta, OpenIndiana, and other groups interested in an open-source ZFS) are working on a way to extend ZFS without using the same version numbers as Oracle. A first RFC has been posted on the zfs-discuss mailing list.
Thus, regardless of what Oracle does, open-source ZFS will continue to be developed.
This is unfortunate. I have mixed feelings about ZFS vs Btrfs.
– ZFS has been tried in the field and works very well. It was revolutionary if you will. I don’t think ZFS is going to be replaced in Solaris, Nexenta, or FreeBSD any time soon.
– Rather than use Btfs, I’d like to see ZFS omnipresent as administrators only need to learn and plan for ZFS strategies
– Since ZFS on Linux efforts appear to be fading, and Btrfs efforts seem to be increasing, it looks like we’re going to have fragmentation in the filesystem arena.
Don’t get me wrong – I know that OSS is all about choice, and that aspect usually translates into a “good thing”. But sometimes, it really does feel redundant, unnecessary, and problematic.
The good news is that things keep getting better and better, and I’m guessing within a year Btrfs will see it’s day on production systems.
Cheers.
“we’re going to have fragmentation in the filesystem arena. ”
I see what you did there
This has always been the case.
So much so that UFS on many UNIXs is incompatible with UFS on other UNIXs.
Well, the only reason ZFS isn’t in Linux is because of the license. And no-one would be surprised if that is what Sun choose to use that license.
Even Sun at some point had plans to use Linux and ZFS together for Lustre-projects.
After all Lustre is already a pretty patchset against mainline Linux-kernel and as they control the code they can sell it like that to customers without it being a big problem.
Edited 2011-06-16 09:37 UTC
I’d be far more worried about the schism between ZFS on Solaris and ZFS on everything else than “fragmentation in the filesystem arena”. There’s never been a be all end all filesystem, there never will be. Even if there magically was one somehow that solved all the use cases in the bet possible way, ZFS wasn’t going to be it. Ever.
was always that it was being done by KQ Infotech. No offense to the talented engineers that worked for the company, but they weren’t known to have a sustainable business model. If I were an admin trying to decide what file system to use, I wouldn’t choose a solution that was supported/developed by a company without proven staying power. It would be better to just use FreeBSD – ZFS for anything critical.
I know it was started by and has been picked back up by LLNL, but still wouldn’t adopt it.
Yeah damn Indians! How dare they merge or sell their companies!
It has nothing to do with their nationality. Just their lack of a reputation and history in the industry. Storage providers should have a proven track record before being trusted with critical data. Its common sense, not xenophobia.
Whilst I know what you mean, this strikes me as something of a chicken-and-egg problem for entering the field
Yeah, its not easy entering into the enterprise data storage market. Nor is it easy entering into the life preserving medical equipment field. A high barrier to entry is a good thing in some industries. I’ll not apologize for its necessity.
Not really. You’ll get hobbyists, non-production / test systems and perhaps even small start ups adopting newer technologies; trialling them for production and enterprise users. Much like bleeding edge Linux distros and users that run “unstable” (et al) repositories provide valuable testing and bug reports so that the more server-focused distros have more assurances about which packages to push into “stable” and which patches to back-port.
You just wouldn’t expect an enterprise to use an unproven storage technology any more than you’d expect them to be running “unstable” / “testing” repo’s on their core servers.
Hmm. You shouldn’t expect it perhaps. I suspect it’s more common than it should be though
Still – I’m no economist, but I would think industries with high barriers to entry and where economies of scale drive towards big players, would lead to oligopolies or monopolies and we all know where that ends up in IT…
True that. However, when the bulk of your work isn’t in the mainline kernel its not going to get as many of those early adopters. Btrfs only has a chance to make it because its being used by people in less stressful/ less important situations FYI, I’m running Fedora 15 now so I’ll probably be on BTRFS when 16 drops. So Yeah, I am calling my own data less important.
Have you never seen the countless discussions among geeks/IT folks about how all development work are given to incompetent foreigners? And (only partially made up) “Oh by the way the support had a slight Indian accent so I began screaming to make my self understood”. And I’m not talking about standard insecure clueless lusers :/
Iv’e only encountered that online. I actually interned with a firm that had a department in Pune, India. For rush projects we’d work for 8 hours on it then they would. I never had any problem with the quality of work they did. Honestly, the their national origin was not in my thought process when I wrote that original post. I’ve met idiots from every corner of the world, and really smart people from the same corners. A nationality/ place of origin does not define a person’s intellect.
This situation is not ideal, but it is working out fine. Fortunately ZFS isn’t needed enough to seriously develop it. BTRFS full steam ahead.
Your post doesn’t really make sense:
If ZFS isn’t needed enough to seriously develop, then why is BtrFS in development as surely that isn’t needed seriously either? And that’s ignoring the fact that ZFS /is/ still being developed.
It makes perfect sense. BTRFS obsoletes the need for ZFS on Linux. It was created to do this.
Right I follow your point now, however I do think it’s a touch elitist to say that BtrFS obsoletes the need for ZFS on Linux when ZFS is already in enterprise usage and BtrFS is still beta quality. Furthermore I thought Linux zealots were all about freedom of choice.
Now you’re just making conversation. All you need to know is that a serious port of ZFS to Linux has always been impossible because they use different licenses. It is not about choice or NIH syndrome, it just couldn’t be done.
Well yes it could be done. All the licenses said was that Sun/Oracle ZFS source code couldn’t be shipped in pre-compiled GPL binaries.
There is nothing stopping:
a/ a complete GPL re-code (which is obviously what KQ was working on)
b/ CDDL code running in user space (hence the already available ZFS-FUSE packages)
c/ CDDL code being compiled into the Linux kernel locally (ie like how propitiatory graphics card drivers used to be – and possibly still are – compiled into Linux).
Each has their own pro’s and cons. Whether it’s a performance penalty, shipping restrictions or just plain development time, each method isn’t without it’s set backs. However it can still be done.
In fact, Sun themselves have said ZFS can be rebuilt in GPL and even pointed towards their ZFS drivers for GRUB (which had to be licences GPL due to GRUB being a GNU/GPLed bootloader) as a working example. However I don’t know if KQ have been building upon Sun’s GRUB code or if KQ was re-engineering their file system driver from scratch.
A is not a port and B and C are not serious.
True, but now you’re just arguing semantics.
while I can understand users dismissing running ZFS in user space for the obvious performance penalties, but option C is a serious option in terms of usability. As I said before, the same principle already happens for other Linux drivers (namely propitiatory graphics drivers)
given that they are the developers of both, ZFS and BTRFS, now.
They are the only developers of ZFS, but one of several developers of Btrfs. That may influence their decision. On one hand, they have a deep legacy investment in ZFS and customers that depend on it. On the other hand, development cost for Btrfs are shared.
I think it really depends on how well Solaris continues to sell. If Solaris ever looks like its dying, they’d either GPL or Kill ZFS.
They are the only developers of Oracls ZFS. There are many developers of the non-Oracle, open-source ZFS. And development of the OSS ZFS is no longer dependend on Oracle.
ZFSv28 has been released as open-source, there’s no way to “kill” it.
As mentioned in the original article and obvious by the zfs linux site att llnl the code has been merged back into upstream
Well, this was obvious when KQ Infotech was bought by STEC. This company is mainly known for providing SSD for Sun/Oracle ZFS appliances. It was obvious that STEC was used as proxy by Oracle to stop KQ work on ZFS.
So are you saying that Oracle bought the company to stop work on ZFS? So, every company that works on porting the CDDL open sourced ZFS, will be bought by ORacle?