Return to jim-mostek.txt CVS log

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

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

From: Jim Mostek <mostek@sgi.com>
Newsgroups: mail.linux-kernel
Subject: Re: SGI's XFS DONATED AS OPEN SOURCE!!!!!!!!!
Date: 29 May 1999 02:29:40 -0700
Organization: Silicon Graphics Inc., Mountain View, CA
Lines: 40
Sender: root@fido.engr.sgi.com
Approved: mailnews@fido.engr.sgi.com
Distribution: sgi
Message-ID: <7ioc24$h0pje@fido.engr.sgi.com>
NNTP-Posting-Host: fido.engr.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

>
>Hi!
>
>> That's it. No more, no less. You can read more here:
>>
>> http://www.news.com/News/Item/0,4,36807,00.html?st.ne.fd.tohhed.ni
>
>No need to shout, we have all seen it on ./ ;-)...
>
>BTW I would say hooray at the time someone makes it working with
>Linux. Having filesystem is nice, but integrating XFS into linux may
>be well more work than writing journaling filesystem from scratch. (Or
>maybe SGI is going to do work for us?) There are some non-trivial
>issues buffer cache.

SGI is doing some page cache/buffer cache internally to support
XFS. As far as I know, this will be part of the Open Source'ing (I haven't
heard differently). SGI is pumping people power into getting XFS (and
other stuff) into Linux.

Jim

>
>                                                               Pavel
>
>--
>I'm really pavel@ucw.cz. Look at http://195.113.31.123/~pavel.          Pavel
>Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
>
>-
>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/
>


-
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: Jim Mostek <mostek@sgi.com>
Newsgroups: mail.linux-kernel
Subject: Re: XFS and journalling filesystems
Date: 28 May 1999 23:58:16 -0700
Organization: Silicon Graphics Inc., Mountain View, CA
Lines: 81
Sender: root@fido.engr.sgi.com
Approved: mailnews@fido.engr.sgi.com
Distribution: sgi
Message-ID: <7io368$gp849@fido.engr.sgi.com>
NNTP-Posting-Host: fido.engr.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

>
>
>Andreas,
>
>Journalling slows everything down because it requires all writes (and reads)
>to be serialized.  This decreases SMP parallelism.  The last thing Linux
>needs is another slow SMP poor component.  I think more is better, don't get
>me wrong.  I jsut didn't like seeing some folks go belly up and start
>killing their internal projects (like ext3) just becuase XFS shows up on the
>scene.  Particularly since it was a patently blatant predatory move by SGI
>based on pure politics -- so obvious.  It's also just another unix file
>system, and comes with all the limitations of Unix FS's.
>
>Jeff

It depends on how you do (journalling sp??). XFS has an async log so meta data
operations get clumped into a single log write to disk (for several) ops (usually).
Most other journal FS' don't do this. In fact, the only one that does
async logging that I'm familiar with is XFS. I saw Stephen's design
doc and he talks about bundling up the meta data operations, too.

XFS does a really good job on SMP parallelism compared to other Operating
systems and file systems that I've seen. This is what it was designed for.
Parallelism/SMP issues must be done in cooperation with other OS
components (like a kernel_lock or lack thereof :-)). XFS on IRIX has lots
of nice fine-grained locks. This allows many threads to be working on
various things at the same time. I'm not sure how much of this will
survive the port to Linux, though.

From what I see, SGI is committed to Linux as one of their future OS'.
They are trying to make it better. The intent of releasing XFS is not
to squash other project, but to make Linux better (IMHO).

The XFS port of Linux will take lots of work and won't be a simple. It is
going to need lots of changes to fit and work well in Linux.

Back to code,

Jim

>
>
>----- Original Message -----
>From: Andreas Bogk <andreas@andreas.org>
>To: Jeff Merkey <jmerkey@timpanogas.com>
>Cc: <mcai7et2@stud.umist.ac.uk>; <linux-kernel@vger.rutgers.edu>
>Sent: Monday, May 24, 1999 8:57 AM
>Subject: Re: XFS and journalling filesystems
>
>
>> "Jeff Merkey" <jmerkey@timpanogas.com> writes:
>>
>> > much of it they are really going to give you.  Another Unix File system
>> > (yawn yawn yawn) with journalling (which means it will be **SLOW**).  I
>> > would vote for the ext3 project to continue.  It appears they were
>reacting
>>
>> I'm using Linux for video applications. XFS has a very important
>> feature for video: guaranteed bandwidth. Also, journalling slows down
>> reading, but speeds up writing, which is again important for
>> video. So, as long as ext3 is not there, I'll be very happy about XFS.
>>
>> Andreas
>>
>> --
>> Reality is two's complement. See:
>> ftp://ftp.netcom.com/pub/hb/hbaker/hakmem/hacks.html#item154
>>
>
>
>-
>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/
>


-
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: Jim Mostek <mostek@sgi.com>
Newsgroups: mail.linux-kernel
Subject: Re: XFS and journalling filesystems
Date: 29 May 1999 03:06:13 -0700
Organization: Silicon Graphics Inc., Mountain View, CA
Lines: 35
Sender: root@fido.engr.sgi.com
Approved: mailnews@fido.engr.sgi.com
Distribution: sgi
Message-ID: <7ioe6l$h1s3u@fido.engr.sgi.com>
NNTP-Posting-Host: fido.engr.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

>
>> 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?
>
>XFS is 50,000 odd lines of mainframe class filing system code. Its unlikely
>to be the ideal fs for a small appliance or a desktop at home even if
>it kicks butt as a server fs.

More like 100,000 lines+. But, I'm not sure what will wind up in Linux.
There are two directory formats (old/new) and only one should go into Linux.
This should save about 10K. Other stuff is on the side like the extended
attributes and they really don't impact the main code.

Why do lines of code restrict what makes an fs ideal for an appliance
or desktop?

Jim

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


-
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: Jim Mostek <mostek@sgi.com>
Newsgroups: mail.linux-kernel
Subject: Re: XFS and journalling filesystems
Date: 29 May 1999 22:53:54 -0700
Organization: Silicon Graphics Inc., Mountain View, CA
Lines: 100
Sender: root@fido.engr.sgi.com
Approved: mailnews@fido.engr.sgi.com
Distribution: sgi
Message-ID: <7iqjpi$h5vve@fido.engr.sgi.com>
NNTP-Posting-Host: fido.engr.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII


Jeff,

XFS does not put data into the log. It keeps track of meta-data operations
in the log. One goal of XFS is to remove the need for fsck at start-up.
This is a very big deal when one has very large file systems. fsck can
take a very long time on very large file systems.

If you are looking for a file system that logs data, XFS is
not your solution. XFS does allow a file to be written synchronously
with O_SYNC so you can guarantee that the data is on disk
when the write returns.

There is much more to XFS than the log and journalling.
Saying that because XFS doesn't log data, it is no better than NTFS
doesn't address all the other aspects of XFS.

Have you seen the latest XFS white paper? The current one off of SGI's
web page is pretty old. The latest paper compares NTFS, XFS,
VxFS and is a pretty good overview of XFS. XFS has had more
stuff added to it in recent months (like a new defag tool)
which is not in the paper.

I just looked around and I don't see a publicly available web
jumper for it. We'll set one up and I'll send it around next
week.

Jim

>
>
>Jim,
>
>Some journal based FS's will serialize reads when A) there is cached data
>(in a buffer cache for example), and there is a requirement for writes to be
>committed real time with reads always having the most current data, and B)
>when transactioning is implemented above the FS and you have writes and
>reads to the same block (do you return the stale data, or do you return the
>write that was posted to the journal and cached, but not yet committed?)  In
>theory, you could avoid serializing on reads, but you may get stale data.
>
>This applies to journalled FS's that post both user data and meta data to
>the log file.  NTFS, for example, only posts meta data to the log file for
>restart, and does not post user writes to the journal.  This means you can
>lose user data on a restart.  If XFS is only writing meta data to the
>journal, and not user data, as you suggest, then you are technically correct
>that reads do not have to be serialized, however, this also means that XFS
>is not a **TRUE** journalling file system because you can lose user data on
>restarts, and the benefits it provides for journalling are not much better
>than running "fsck" after a system crash.
>
>Surely this is not the case -- this would mean that XFS is no better than
>NTFS.
>
>Jeff


From: Jim Mostek <mostek@sgi.com>
Newsgroups: mail.linux-kernel
Subject: Re: XFS and journalling filesystems
Date: 1 Jun 1999 12:38:17 -0700
Organization: Silicon Graphics Inc., Mountain View, CA
Lines: 33
Sender: root@fido.engr.sgi.com
Approved: mailnews@fido.engr.sgi.com
Distribution: sgi
Message-ID: <7j1cr9$ib3mq@fido.engr.sgi.com>
NNTP-Posting-Host: fido.engr.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII

>
>==> Regarding Re: XFS and journalling filesystems; Jim Mostek <mostek@sgi.com> adds:
>
>mostek> added to it in recent months (like a new defag tool) which is not
>
>will this defrag tool (and any other user space maintainence tools) be
>released along with the actual XFS source code?
>

The defrag tool has code in the OS since it does a transaction.
I don't see why we wouldn't release it with the rest of XFS. But,
we haven't decided on the all the pieces that will be in the first release.
I imagine it would be released at some point.

Jim

>--
>Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net  | PGP key available
>paramount.ind.wpi.edu RedHat 5.2 kernel 2.2.5        i586 | at public servers
>To Perl, or not to Perl, that is the kvetching.
>             -- Larry Wall in <199801200310.TAA11670@wall.org>
>