Messages in this thread | | | Date | Sun, 23 May 1999 20:37:33 -0400 | Subject | Re: XFS and journalling filesystems | From | tytso@mit ... |
| |
Date: Fri, 21 May 1999 00:06:28 +0100 From: Edward Thomas <mcai7et2@stud.umist.ac.uk>
In light of the recent announcement by SGI (that the core of the XFS journalling filesystem will be opensourced this summer) what is "the panel's" view of the continuing devlopment of ext3/whatever the linux jfs will be called. Should we adopt XFS as the defacto replacement for ext2?
I've talked to the SGI folks, and there are a couple of things to keep in mind as you read their press release. First of all, they have just made the decision to release it under an Open Source(tm) license; they have not yet committed to using the GPL. If they use an Open Source license (such as one similar to the Apple or Mozilla Public License) which is not compatible with the GPL, then putting it into the kernel sources would be a problem; it might have to be distributed separately from the kernel.
Secondly, they still need review the XFS code they intend to contribute for copyright and patent encumberances from other companies, and to actually port it to Linux. So it will be a while before we even have a chance to look at the contributed code to evaluate it, and even longer before it will be ready for prime-time use in the Linux kernel.
Finally, I'm told that when XFS was first introduced into Irix, significant changes needed to be made to its VM layer to support XFS. If any changes are required, they will have to be clean enough so that Linus will approve them. If they are horribly ugly and grotesque, we all know that Linus will turn them down flat-out.
(And there are certain features of XFS, such as the features that allow Irix to tell the disk controller to send disk blocks directly to the ethernet controller, which then slaps on the TCP header and calclates the TCP checksum without the disk data ever hitting memory, which I'm pretty confident we won't be supporting in Linux any time soon. It's a cool idea conceptually, the implementation and maintenance headaches it causes are generally acknowledged to be not worth it. It's a pain even if you control all of the hardware, such as SGI did. I don't even want to think about what it would be like to try supporting this on generic PC hardware.)
So the bottom line is that I would be very, very, suprised if XFS for Linux took less than a year (or more) to become a reality. That being said, XFS is a very nice filesystem, and the white papers that I've read about it shows that it's something which SGI was very generous to donate and which no doubt will be great for Linux. However, there's some work that needs to be done before first before it will become a reality. If there are implementation issues, either because SGI doesn't release it under a GPL-compatible license, or because their implementation requires VM changes which Linus refuses to accept, one option may be to look at the XFS filesystem format and do our own clean, from-scratch implementation which takes the ideas from XFS and is XFS-format compatible. There are many different options available to us.
Also, we can't discount the possibility that as a result of SGI deciding to Open Source XFS, Compaq might not decide to do the same thing with their advfs, which is also a truly wonderful filesystem which urrently ships with their Digital Unix OS. If that happens, we will be in the happy position of having two very well-designed filesystems to evaluate and choose from.
So my personal perspective is that XFS is a very promising filesystem for us, but it's not ready yet. In the short- to medium- term, both Stephen Tweedie and I will be working on improvements to ext2fs so that people who need solutions sooner than when XFS will be available will have something they can use. In the long term, XFS is undoubtedly a very interesting prospect to consider.
- Ted
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |