Submitted by The (unstable and development-oriented only) filesystem Btrfs version 0.14 has been released. “Btrfs is a new copy on write filesystem for Linux aimed at implementing advanced features while focusing on fault tolerance, repair and easy administration. Initially developed by Oracle, Btrfs is licensed under the GPL and open for contribution from anyone.”Besides the obvious bug and performance fixes, the email announcement lists the main new feature of this release:
The major new feature is the ability to manage multiple devices under a single Btrfs mount. Raid0, raid1 and raid10 are supported. Even for single device filesystems, metadata is now duplicated by default. Checksums are verified after reads finish and duplicate copies are used if the checksums don’t match.
The stable release can be downloaded from here, and the source repositories are here. Don’t miss the big warning, though: “Btrfs is under heavy development, and is not suitable for any uses other than benchmarking and review. The Btrfs disk format is not yet finalized.”
http://btrfs.wiki.kernel.org btrfs homepage for the adventureous
If it is as stable, this will very likely replace ext3/4 as the default linux filesystem in most major distros.
per directory snapshots and cow have been
Although in a very early state I’m soooo excited about this filing system. In stead of whining about ‘ZFS for Linux’ I think this project has a higher change of succeeding in being the ‘next-generation’ filing system for Linux. I’m not saying it’s better than ZFS, but is doesn’t have the political issues of ZFS.
Also I get the idea that kernel community is waiting in anticipation for this stuff. And now Hans R. is probably going to jail for a long time we can forget Reiser4…
Long live BTRFS!
What political issues? The only problem of ZFS, as far as Linux is concerned, is that its license is GPL incompatible.
Licensing is political. NIH is also a political issue.
But the problem is that GPL is too restrictive. Thus ZFS couldn’t be included in Linux kernel and Btrfs(also GPL) won’t be easily included in other operating systems. If I understand correctly…
sun could make zfs gpl. there was talk about it as a trade for linux kernel drivers.
but they chose not to because they are launching new products that use it, and it is a big differentiating feature between them and linux.
That’s life. Seriously. Choices have consequences, and some of them are beneficial and some of them are not. It is unlikely that ZFS will see inclusion in the Linux kernel, and it is unlikely that btrfs will see inclusion in the *Solaris kernel. (Should that be plural or not?) Sometimes those kinds of barriers are significant, and sometimes they are not. I am not convinced that the sharing of filesystem code has much benefit over cross-pollenation of *ideas* in this particular case, for reasons which I have outlined elsewhere in this thread.
I find that discussions on licensing often end up doing nothing more than generating bad blood and resentment between the various parties, without yielding any meaningful benefits.
An impedance mismatch between the ZFS architecture and Linux kernel architecture is *not* political, however. Sun’s goals for ZFS, apparently, are for it the be the Solaris filesystem. And there is absolutely nothing wrong with that. That strategy has its strengths. And in that case, putting the layering of logical levels into ZFS itself makes perfect sense. However, supporting a broad range of filesystems is a strategy which also has its strengths, and that is what Linux does. In that case, having all the layering of raid, volume manager, fs, etc. in ZFS itself makes no sense at all.
No NIH is required to see that ZFS, while a good fit for Solaris, is a poor fit for Linux.
As to licensing… that does have a political aspect. But the problem is primarily a practical one from the Linux kernel devs standpoint. Although an argument could be made that Sun’s choice of license might have been motivated by political (or perhaps “strategic” would be a better word) factors.
Edited 2008-04-30 16:44 UTC
I don’t think that argument holds, since Btrfs is busy copying all the “layer violation” features from ZFS such as RAID.
No. That is a mischaracterization. Btrfs is intended to work closely *with* dm and lvm. A certain minimum amount of functionality is duplicated between btrfs and the current dm and lvm where absolutely necessary. Read what Chris says about this:
http://lwn.net/Articles/265533/
Edited 2008-04-30 17:59 UTC
So? What makes ZFS completely unsuitable for Linux is the fact that it’s not just a filesystem – not even a “filesystem + volume manager”. ZFS is a complete software stack from the VFS to the storage driver.
This is why ZFS supports io priorities and UFS-solaris doesn’t: They have the “old” IO stack and the “new” ZFS stack. In the Linux kernel this would not be acceptable at all. When Linux develops a new piece of the IO stack such the io priorities, it must work for all the filesystems. If that piece only works with a filesystem, it’d be considered misdesigned and would not be merged. This is why in Linux you have IO priorities support not only for a given filesystem like ext3, but also for filesystems like FAT – for any kind of filesystems, in fact the io priority thing doesn’t interacts so much with the filesystems, but with the block devices.
So if ZFS were GPL, some parts would be need to be redesigned to be merged in Linux. BTRFS, in the other hand, is just a filesystem that plugs cleanly in the Linux design.
In general I don’t think you are incorrect. However, I don’t think this is literally true. For instance, I am pretty sure that each major Linux FS implements journaling using its own private subsystem. There is a standard subsystem now, JBD, but only ext3 uses it.
Moral of the story is, if the right political factions are behind it, anything goes.
I would disagree with that. Duplication of journaling layer code is one thing. Especially considering that XFS, JFS, and Resierfs were introduced before jbd and ext3. It’s an unfortunate situation, but what can we do now? Rewrite them all to use JBD? Reiserfs was introduced back when we Linux folks had a pretty bad case of “journal envy”. XFS (and to a lesser extent, JFS) carried too much of a mystique to refuse. Those were different times. If reiserfs v3 were new today it would not get the easy ride that it did back then, Hans or no Hans.
Besides that, JBD holds a different status than, say, VFS, DM, MD and LVM. ZFS’s wholesale duplication of pretty much the whole stack is in a completely different class of design dissonance than simply using one’s own journaling layer.
I don’t understand why people are so quick to claim politics when the technical reasons for concern are so clear. I think that it’s maybe because these kinds of threads spend so much time in “conflict mode” where honest expression of concerns about impedance mismatches quickly devolves into “ZFS Rulez!, ZFS Sucks!” affairs.
My position is that ZFS is great for Solaris, and bears a lot of good ideas that many of us would like to see in a Linux filesystem. But I really don’t think that porting ZFS is the answer, even disregarding the obvious licensing issues. The desirable features of ZFS really need to be added in the appropriate places in the Linux stack to really work well and have a chance of becoming default Linux filesystem features. ZFS is a round peg. *Solaris is a round hole. Linux is a square hole, and needs a square peg with all the nice features of the ZFS round peg included in the appropriate places. Btrfs is a pragmatic start on that. It is, in my opinion, just ambitious enough, but not *too* ambitious to be a practical starting point. (We should not expect always to be on the cutting edge of everything. A little patience, and appreciation of others’ achievements is called for.)
This discussion would really be more interesting if the subject were ZFS’s suitability for MacOSX or FreeBSD where the licensing allows the question to be relevant. And, of course, the designers of those kernels are entitled to their own ideas about what is appropriate in their kernels. After all, they are the ones who must support these filesystems on into the future.
Edited 2008-04-30 20:45 UTC
You are right in that the reasons are historical. However, if there was true fear and loathing about the duplication of subsystems, the “problem” would be fixed. What I am suggesting is that there is always a pretty bad case of something envy that will cause these principles to be broken. Sometimes this is fixed later, sometimes not.
Agree about VFS, not so sure about the rest. It is clear that btrfs will duplicate a bunch of functionality in DM / MD / LVM, and I think his reasons for this are good.
Because politics are at least as, if not more, important than technical issues. If this was not so, I’d bet that I’d be writing this from a Alpha / Tru64 based workstation, maybe with Display PostScript instead of X
Right on.
Yeah, I’d love to hear some feedback from those folks. Actually, since I have been too short on time lately to do some testing, anyone with recent btrfs experiences?
I think it is more a matter of “Do we add allow new code to add to the problem?”. To me its pretty clear that the bar is set much higher today. Linux has grown up a lot since those heady days of 2.3.x-test. Linux was a teenager back then. Today, it is a young adult with adult responsibilities, and the kernel devs seem more mindful of that.
As many nice features as ZFS has, I don’t see anything near the level of urgency today as I saw regarding journaling back in the pre-ext3 days. Ext4’s extents, new volume size limits, and recent improvements to fsck speed will be sufficient to tide us over until something btr^better is ready. Haste makes waste. And there is no need to repeat mistakes due to excessive impatience today, in 2008.
I only wish that fewer people felt the need to throw rocks at ZFS. Sun concentrated on one filesystem that fit their needs well, and they came up with something nice. There is no shame in that for the rest of us. And there’s really no call for the “sour grapes” attitude I’ve seen expressed by a few people.
Edited 2008-04-30 21:04 UTC
You’re right…it being GPL, it has its own political issues.
ZFS and the Linux kernel are incompatible. End of story.
Edited 2008-04-30 20:48 UTC
I wonder why we haven’t seen any implementation of ZFS in the Linux kernel.
Just because something is illegal doesn’t mean the community won’t work on it. Look at XBMC, although now it has a Linux port, it was originally made for hacked xboxes using an illegally acquired and unlicensed XDKs. That didn’t stop people from working on it and hosting the binaries in some country that doesn’t care about those issues.
Would it be illegal to ship a compiled Linux kernel along side some ZFS source code that has been modified to work with the kernel, and then supply a script to compile it as a module?
I definitely see how shipping a kernel binary with that support built directly into it would be illegal. But if you leave it to the end user to build it is it illegal?
Would it be illegal to ship a compiled Linux kernel along side some ZFS source code that has been modified to work with the kernel, and then supply a script to compile it as a module?
I definitely see how shipping a kernel binary with that support built directly into it would be illegal. But if you leave it to the end user to build it is it illegal?
That would still be illegal. If you really, really need ZFS that bad then I’d suggest to go to http://zfs-on-fuse.blogspot.com/