Return to ralf-baechle.txt CVS log

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

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

From: Ralf Baechle <ralf@uni-koblenz.de>
Newsgroups: mail.linux-kernel
Subject: Re: [OT] SGI to OpenSource XFS
Date: 28 May 1999 08:37:16 -0700
Organization: uni-koblenz.de
Lines: 22
Sender: root@fido.engr.sgi.com
Approved: mailnews@fido.engr.sgi.com
Distribution: sgi
Message-ID: <7imd7c$gde1i@fido.engr.sgi.com>
References: <ApTj9D.A.AsD.XBHS3@tequila.cs.yale.edu> <5lyaif8mee.fsf@tequila.cs.yale.edu>
NNTP-Posting-Host: fido.engr.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii

On Sun, May 23, 1999 at 06:13:45PM -0400, Stefan Monnier wrote:

> >>>>> "Paul" == Paul Jakma <Paul.Jakma@Digital.com> writes:
> > Apparently SGI will be open-sourcing XFS - to be announced at Linux Expo.
>
> XFS has some nice features such as journalling, dynamically managed inodes,
> B-tree directories, and real-time features for multimedia streams (looks like
> this last one will not be in the open-sourced code).
> But how about performance ?  Does anybody have comparisons of various
> filesystems in terms of performance ?

SGI has demonstrated r/w 7gb/s from a single filedescriptor on the apropriate
hardware.  Other engineers have told me that in none of the benchmarks they
have done for customers XFS has ever been the bottleneck.  Actually the only
point where XFS' performance sucks is when rm -rf.

  Ralf

-
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: Ralf Baechle <ralf@uni-koblenz.de>
Newsgroups: mail.linux-kernel
Subject: Re: XFS and journalling filesystems
Date: 31 May 1999 03:00:30 -0700
Organization: uni-koblenz.de
Lines: 30
Sender: root@fido.engr.sgi.com
Approved: mailnews@fido.engr.sgi.com
Distribution: sgi
Message-ID: <7itmju$hkofl@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

On Sat, May 29, 1999 at 06:48:19AM -0400, Vilain, Sam wrote:

> As a dangerous rule of thumb, LOC ~ code size.  More code size = bigger
> kernel = less (buffercache|user memory).  <flamesuit>This is a fear of Linux
> kernel developers - Linux ending up as slow as say, Solaris on low end
> machines (even if it kicks butt on 6144-way SMP).</flamesuit>

Nobody builds 6144-way SMPs, not Sun nor somebody else.  The SMP paradigm
just doesn't scale that far.

> Numbers are often good in arguments like this.  ie, how big is the ext2fs
> module under Linux/MIPS, compared to the xfs module under Irix?  [Comparing
> with Linux/i386 should probably be avoided, because i386 code is (generally)
> more instructions/word, even if you need a few extra million transistors to
> decode it :)].

[ralf@lappi linux-sgi]$ mips-linux-size fs/ext2/ext2.o
   text    data     bss     dec     hex filename
  60080     496    1024   61600    f0a0 fs/ext2/ext2.o
[ralf@lappi linux-sgi]$

The archive /usr/cpu/sysgen/IP22boot/xfs.a of IRIX 6.2 has in total a
.text size of 274864.  That's 32 bit code btw.

  Ralf

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