Submitted by “Following up on our introductory article on Btrfs, Jeff Layton talked with Chris Mason, Director of Linux Kernel Engineering at Oracle and the founder and lead developer of Btrfs.”
“Following up on our introductory article on Btrfs, Jeff Layton talked with Chris Mason, Director of Linux Kernel Engineering at Oracle and the founder and lead developer of Btrfs.”
Personally I feel this sort of story belongs on page one of OS news.
Even though it doesn’t make much sense, the real difference between “Front Page” and “Page 2” is whether the staff just links to the piece with a quoted blurb, in the case of the latter, or whether they give more information in the form of original reporting, usually indicated by the “Read more” link.
That’s why very interesting material ends up on “Page 2”, which — if it were a newspaper — would indicate it is of less interest, whereas anything that gets a custom writeup goes on the “Front Page’.
(The fact itself that this isn’t immediately obvious should indicate that it’s not an improvement to a combined page.)
The article made it clear once again, that BtrFs is a copy of ZFS. Same as SystemTap.
Maybe Oracle will sue Oracle .. you’ll never know.
The part that I love is how the filesystem is trying to incorporate all the RAID stuff that is in md. Eventually, the goal appears to be to completely remove the md layer, putting it all in the filesystem. The fact that you use the filesystem formatting tools to create the RAID levels should be a big warning sign that they’re doing things wrong … but that doesn’t seem to matter to them. If things continue on this way, md, lvm, and the filesystem itself will all be in one big blob, all managed via mkfs.btrfs.
I seem to recall that this is the exact reason that all the kernel devs railed against ZFS when it was first released as open-source for others to use.
In ZFS, you’d use zpool to create the underlying raids, and zfs to manage the file systems on top – I hope it’s not too optimistic to assume they’ll do something similar.
Just goes to show, if nobody’s figured it out yet, that the Linux ecosystem is starting to contract a very nasty case of NIH syndrome. ZFS -> BtrFS, DTrace -> SystemTap, OSS -> ALSA/Pulseaudio, etc…
It has nothing to do with NIH. Both ZFS and DTrace have incompatible licenses. Also if you read the article BTRFS is not a copy of ZFS. It has some similar features but it is not a clone in the slightest. OSS failed on Linux because the GPL version was lacking a ton of features and instead of waiting and wondering if OSS would ever be fully open Linux developers decided to create their own working framework. Pulseaudio is a sound server, the only thing it has in common with ALSA is that both have mixing capabilities.
Yes, licensing makes a very convenient scapegoat… doesn’t help the users when they’re saddled with an inferior system though, and either way it does result in NIH in the end.
Yes, licensing makes a very convenient scapegoat…
So, what do you expect them to do? Ignore the license? If the two license are incompatible then they are and the source-code cannot be legally combined. Period. If you ignore the license then what’s the point in having a license in your own software either?
You should think things through a little bit better next time. If ZFS did have a compatible license I have no doubt it’d have been in Linux kernel already for a long, long time. There’s so many people who like it and it’s not fun to have to code similar functionality because of just an incompatible license.
Hmmmmmm, that’s funny. I fail to see how the GPL can be made to be restrospectively CDDL compatible just because ZFS is so brilliant.
A side effect of Sun’s creation of the CDDL was that it ended up being incompatible with an existing license, the GPL, some would say needlessly. Whether that was by accident or by design is of no matter however. The situation is what it is. You idiots like to make it sound as if the GPL was made to be CDDL incompatible, but that’s just totally illogical I’m afraid.
Edited 2009-05-17 15:10 UTC
Not it doesn’t result in NIH. It results in “we cannot use this software becuase it is not LEGALLY allowed”. You don’t just break licensing agreements because you feel like it. I think Linux developers have better things to do than fight legal battles. By the way, calling Linux inferior because of the lack of availability of Dtrace and ZFS is seriously overestimating the importance of those technologies.
I don’t know where you get that strange idea from. Chris Mason has said quite clearly that Btrfs will be using as much of the md layer as it possibly can because it would be silly to rewrite it. We also have no idea how that will be structured yet. The only thing we’ve got going on here is that the filesystem now has to know certain things, such how to get another copy of the data from the RAID subsystem, which it didn’t need to know before. The md subsystem will be getting such additions:
Perhaps a read of the article might be in order?
I also don’t know where you get the idea that the md system is to be removed because there are an awful lot of people using it, and will continue to use it long after Btrfs has been deemed to be stable.
I’m afraid being able to do things from one command bears no reflection at all on the underlying implementation. Sorry.
I know you really want to tell us all that Btrfs is being implemented exactly like ZFS to justify the way that ZFS is structured but you’re wrong I’m afraid.
Gee, I don’t know, maybe because it’s mentioned in the article:
Managing multiple devices inside the filesystem is what gives Btrfs very flexible storage management. Devices can be mixed in size and speed, and over the long term Btrfs will do the right thing to optimize access. Raid levels can also be mixed, using different stripe sizes for data and metadata etc.
and
CM Currently, Btrfs has the ability to RAID the metadata and the data itself. Right now it’s limited to RAID-0, RAID-1, and RAID-10. At this time to get other RAID levels you need to use MD that is in Linux. But RAID-5 and RAID-6 are in Btrf’s future.
That tells me that they won’t be using md to do that raid, they’ll be doing it all in btrfs.
Perhaps you need to re-read the article?
I also don’t know where you get the idea that the md system is to be removed because there are an awful lot of people using it, and will continue to use it long after Btrfs has been deemed to be stable. [/q]
See above. And:
Btrfs on top of MD would work just like any other storage device. By default it will mirror metadata as though it were on a single spindle, and Btrfs would only maintain a single copy of the data. Since Btrfs doesn’t yet provide RAID5 or RAID6, people may want to test with MD to get those features.
and
The main difference between Btrfs raid and MD raid is that Btrfs can detect incorrect data returned by the device with checksums. Even if we don’t get an IO error, Btrfs will know if a block is correct.
Sounds very much like md raid and btrfs raid are separate, distinct, different things, and that btrfs raid will supplant md raid.
Later in the article, it mentions that they use some of the md code, but that it will be sucked into btrfs and not kept separate:
Christoph Hellwig is working on abstracting out parts of MD, but he’s starting with integrating that into the DM modules. Long term I want btrfs to use as much of the existing MD code as possible, but the place it makes the most sense is for the xor calculations.
But, that still moves things around. If you use btrfs you can’t use md separately to access the data, and vice versa.
The fact that they are still calling it just a filesystem when it is so much more (like ZFS) is also annoying.
I know you really want to tell us all that Btrfs is being implemented exactly like ZFS to justify the way that ZFS is structured but you’re wrong I’m afraid. [/q]
Doesn’t seem like it. Looks the same from here. ZFS has a device layer, a storage layer, a volume layer, and a filesystem layer … all nicely separated and manageable. Btrfs has a device layer, and a filesystem layer, with a bit of hokey volume management added in. Yet somehow the former is a “layering violation” and the latter isn’t. The former has “too much in the filesystem” and yet the latter has more, actually in the filesystem.
Just reeks of hypocrisy and NIH-edness to me.
That tells me that they won’t be using md to do that raid, they’ll be doing it all in btrfs.
Some things just can’t be done properly without moving stuff from md to BTFS itself, so I don’t see this as a problem. And if those things that can’t be done aren’t important to you then BTRFS apparently does allow you to use md instead. Atleast that’s how I understood it.
Doesn’t seem like it. Looks the same from here. ZFS has a device layer, a storage layer, a volume layer, and a filesystem layer … all nicely separated and manageable. Btrfs has a device layer, and a filesystem layer, with a bit of hokey volume management added in. Yet somehow the former is a “layering violation” and the latter isn’t. The former has “too much in the filesystem” and yet the latter has more, actually in the filesystem.
I don’t understand it either. It’s silly. Seems they both do more-or-less the same things and similar ways. But well, I don’t understand the complaint about “layering violation” either; if something just can’t be feasibly well done without violating that unspoken rule of making everything neatly layered then so be it? People shouldn’t get their pants in a twist over it.
Just reeks of hypocrisy and NIH-edness to me.
A bit of hypocrisy, yes, but there’s no way to avoid NIH here. You do realize that they can’t break the license, don’t you? And it was Sun who decided to make ZFS-license incompatible with GPL’ed software, GPL existed way, way before than Sun’s own license.
Hmmmm, no, because Chris explicitly said that Btrfs will be resusing md and features will be added to md so that Btrfs gets what it needs.
Managing multiple devices within a filesystem and allowing a filesystem to know about devices is not equivalent to pulling and duplicating code wholesale from md, which is the direction you’re trying to go in.
Yep, and Chris still said that they will be reusing md for Btrfs and adding features to it.
Does it? That’s not what Chris explicitly said, and which I pointed out in bold.
Hmmm, nope. I quoted what you missed and you still want to see what you want to see.
Seeing above and it doesn’t state anything which you want to imply.
Yep, that’s if you use Btrfs in a md container which is logical, and if you use Btrfs’s RAID you will still be using the md layer itself. Chris has explicitly stated that features will be added to the md subsystem that will allow communication between the two and in all probability allow other filesystems to implement exactly what Btrfs does without a RAID md container but still using common md code. There’s a little thing called refactoring going on there.
Nope, it doesn’t say that at all. It says they will use md but it certainly does not say that they’ll end up just copying and pasting md and RAID code into Btrfs. If that was the case then they wouldn’t be refactoring md and ‘abstracting it out’.
I know, I know. Alas, you’re still wrong. Sorry.
Edited 2009-05-17 22:05 UTC
Just a question out of curiousity, how come you Segedunum is ALWAYS involved in infected posts like this? I dont get it. Always. Some personal trait of yours. If there is an infected thread here, 80-90% of the time Segedunum is involved.
(I am glad that I am not involved in this).
Yawn. Troll……………. You have nothing to add to the topic once again. For one thing this isn’t an article about Sun or anything Sun related so I wonder why you still take the time to post your inane ramblings. Come to think of it, I wonder how we ever got to attacks on Btrfs by ZFS proponents desperate to point the fingers of NIH syndrome and layering violations. ROTFL.
Too late.
“The article made it clear once again, that BtrFs is a copy of ZFS. Same as SystemTap.”
SystemTap is a copy of ZFS? /boggle