Return to ted-tso.txt CVS log

Up to [Development] / xfs-website.orig / postings

Renamed postings/* to postings/*.txt for better formatting in Netscape

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 <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/


From: "Theodore Y. Ts'o" <tytso@mit.edu>
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 <lm@bitmover.com>

   : (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/