Return to stephen-tweedie.txt CVS log

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

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

From: "Stephen C. Tweedie" <sct@redhat.com>
Newsgroups: mail.linux-kernel
Subject: Re: [was: ext2 question] XFS opensourced!
Date: 28 May 1999 20:29:51 -0700
Organization: redhat.com
Lines: 20
Sender: root@fido.engr.sgi.com
Approved: mailnews@fido.engr.sgi.com
Distribution: sgi
Message-ID: <7inmvf$gns3f@fido.engr.sgi.com>
References: <Pine.LNX.4.05.9905182355340.388-100000@laser.random>
NNTP-Posting-Host: fido.engr.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii


Newsgroups: mail.linux-kernel

Hi,

On Thu, 20 May 1999 11:42:49 +0200 (MET DST), David Weinehall
<tao@acc.umu.se> said:

> Slashdot does have its uses... I read there just a couple of hours ago
> that SGI has/intends to opensource XFS. That'd pretty much solve our need
> for a fast Journaling filesystem, I think.

Yes, _if_ it comes out as GPL and if it gets integrated well into
Linux.  XFS is extremely scalable.  It will be interesting to see how it
compares to ext2/ext3 for smaller filesystems: ext2 is very lightweight
indeed as filesystems go.

--Stephen



From: "Stephen C. Tweedie" <sct@redhat.com>
Newsgroups: mail.linux-kernel
Subject: Re: SGI's XFS DONATED AS OPEN SOURCE!!!!!!!!!
Date: 31 May 1999 19:57:47 -0700
Organization: redhat.com
Lines: 18
Sender: root@fido.engr.sgi.com
Approved: mailnews@fido.engr.sgi.com
Distribution: sgi
Message-ID: <7ivi7b$hf0dr@fido.engr.sgi.com>
References: <19990523213751.K176@bug.ucw.cz>
NNTP-Posting-Host: fido.engr.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Hi,

On Thu, 27 May 1999 12:35:24 -0500 (CDT), Jim Mostek <mostek@sgi.com>
said:

> 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).

Any work done on the core of the kernel will have to be released under
GPL or not at all --- the GPL doesn't give you the choice.

--Stephen


From: "Stephen C. Tweedie" <sct@redhat.com>
Newsgroups: mail.linux-kernel
Subject: Re: XFS and journalling filesystems
Date: 1 Jun 1999 16:26:40 -0700
Organization: redhat.com
Lines: 29
Sender: root@fido.engr.sgi.com
Approved: mailnews@fido.engr.sgi.com
Distribution: sgi
Message-ID: <7j1q7g$i9jkl@fido.engr.sgi.com>
References: <199905281458.JAA62562@fsgi344.cray.com>
NNTP-Posting-Host: fido.engr.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Hi,

On Tue, 01 Jun 1999 02:06:09 -0700, Dan Koren
<dkoren@cthulhu.engr.sgi.com> said:

> This is not a problem in page cache systems like Irix, Solaris or
> SVR4 (UnixWare).

and in Linux.  The fact that there is a buffer cache used for some parts
of the write path doesn't stop us keeping the page cache consistent at
all times.  In 2.3, the two paths will use the same memory anyway.

> File data is kept in the page cache, not in the buffer cache, and the
> same page(s) are mapped or accessed by all the processes that access a
> file. If a process writes to a file the new data becomes visible to
> all readers of the file as soon as the write system call has
> completed.

Agreed, that's what is required by Unix file semantics.  The
cache-to-disk synchronisation semantics are much more relaxed.  Lazy
batching of the metadata transactions on disk is perfectly legal on
Unix.

--Stephen


From: "Stephen C. Tweedie" <sct@redhat.com>
Newsgroups: mail.linux-kernel
Subject: Re: XFS and journalling filesystems
Date: 31 May 1999 19:07:57 -0700
Organization: redhat.com
Lines: 35
Sender: root@fido.engr.sgi.com
Approved: mailnews@fido.engr.sgi.com
Distribution: sgi
Message-ID: <7ivf9t$h9gef@fido.engr.sgi.com>
References: <199905281653.LAA61598@fsgi344.cray.com>
NNTP-Posting-Host: fido.engr.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Hi,

On Fri, 28 May 1999 13:25:33 -0600, "Jeff Merkey"
<jmerkey@timpanogas.com> said:

> getting the NetWare FS (FENRIS) ready for open source next Tuesday,
> hopefully it may be helpful to all, including you guys -- we are putting ALL
> of it under the GPL (less the NT specific IFS code which is about 18,000
> lines oddly enough)).  Sounds like the term "journalling" is like the term
> "clustering" from an industry perspective,

No, it is a true transactional journal with ACID semantics.  It just
doesn't necessarily include data.

> and some FS's aren't really journalled, but reapply this term for
> marketing positioning.

That is the standard definition of the term in the fs community on
Unix.  Sounds like you are the one trying to redefine it!

> A log based file system that logs user writes and allows rollbacks
> is what most folks assume when the term "journalling" is used.

No.  You may be thinking of a log-structured filesystem, but that is
_completely_ different from metadata journaling (which of course
doesn't mean that marketing depts don't sometimes try to confuse
them).  An LFS is necessarily journaled, but not all journaled
filesystems are log structured.

--Stephen

From: "Stephen C. Tweedie" <sct@redhat.com>
Newsgroups: mail.linux-kernel
Subject: Re: XFS and journalling filesystems
Date: 1 Jun 1999 16:49:04 -0700
Organization: redhat.com
Lines: 25
Sender: root@fido.engr.sgi.com
Approved: mailnews@fido.engr.sgi.com
Distribution: sgi
Message-ID: <7j1rhg$id8jp@fido.engr.sgi.com>
References: <76D8782817C5D211A37400104B0C84B029C52F@nz-wlg-exch-1.nz.unisys.com>
NNTP-Posting-Host: fido.engr.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Hi,

On Tue, 01 Jun 1999 02:15:17 -0700, Dan Koren
<dkoren@cthulhu.engr.sgi.com> said:

>> In summary, I guess it is important that the filesystem not only
>> performs at incredible speeds on high end SMP, but also it's best and
>> average case performance on limited memory and IO machines is also
>> good.

> I'm afraid your concerns about kernel code size eating into buffer
> cache or user memory are slightly out of date. These days it seems
> damn near impossible to buy anything with less than 32 MB memory!

The size of the active code paths and their impact on the working set in
cpu L1 cache is still significant even on today's systems.  Every cache
miss you introduce to the primary filesystem code paths hurts, whether
it's a data cache or an instruction cache miss.

--Stephen