Linked by Thom Holwerda on Wed 30th Apr 2008 12:55 UTC, submitted by diegocg
Linux 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 312193
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: excited
by diegocg on Wed 30th Apr 2008 18:44 UTC in reply to "RE[4]: excited"
diegocg
Member since:
2005-07-08

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.

Reply Parent Bookmark Score: 4

RE[6]: excited
by jwwf on Wed 30th Apr 2008 19:24 in reply to "RE[5]: excited"
jwwf Member since:
2006-01-19

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.


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.

Reply Parent Bookmark Score: 3

RE[7]: excited
by sbergman27 on Wed 30th Apr 2008 20:29 in reply to "RE[6]: excited"
sbergman27 Member since:
2005-07-24

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

Reply Parent Bookmark Score: 3