Linked by Thom Holwerda on Wed 30th Apr 2008 12:55 UTC, submitted by diegocg
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."
Thread beginning with comment 312238
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2006-01-19
"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". And XFS just 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. "
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.
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.
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.
I don't understand why people are so quick to claim politics when the technical reasons for concern are so clear.
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
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 the default Linux filesystem.
Right on.
This discussion would really be more interesting if the subject were ZFS suitability for MacOSX or FreeBSD where the licensing allows the question to be even 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 FSes on into the future.
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?
Member since:2005-07-24
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.
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
Recent Original Stories
Recent Comments
Headlines
Random Comments
Random Stories
Random OS Link
Member since:
2005-07-24
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