From: tytso@mit.edu Newsgroups: mail.linux-kernel Subject: Re: XFS and journalling filesystems Date: 24 May 1999 07:35:49 -0700 Organization: mit.edu Lines: 74 Sender: root@fido.engr.sgi.com Approved: mailnews@fido.engr.sgi.com Distribution: sgi Message-ID: <7ibo45$eqm00@fido.engr.sgi.com> References: <37449574.93F56466@stud.umist.ac.uk> NNTP-Posting-Host: fido.engr.sgi.com Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Date: Fri, 21 May 1999 00:06:28 +0100 From: Edward Thomas 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/ From: "Theodore Y. Ts'o" Newsgroups: mail.linux-kernel Subject: Re: XFS and journalling filesystems Date: 28 May 1999 20:29:38 -0700 Organization: mit.edu Lines: 29 Sender: root@fido.engr.sgi.com Approved: mailnews@fido.engr.sgi.com Distribution: sgi Message-ID: <7inmv2$gelak@fido.engr.sgi.com> NNTP-Posting-Host: fido.engr.sgi.com Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Date: Mon, 24 May 1999 11:24:35 -0600 From: Larry McVoy : (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 This is not quite right, in fact, it is a little unfair to IRIX. There is no interaction between the file system and/or the block device system and the networking stack. The way it works is this (I know this code extremely well since I'm the guy that originally made NFS use both the networking and the file system to go at 94MByte/sec - Ethan Solomita is the guy who made it go at 640MByte/second over Super HIPPI): I stand corrected. I had heard about the zero copy algorithm you described, but then when I later heard that Irix had bypassed even the DMA in and out of memory, I was appropriately horrified. I'm glad to hear it wasn't true, and that you had no part in implementing or designing such a horrible hack (i.e., direct device-to-device I/O). :-) - 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/