Re: XFS and journalling filesystems

Re: XFS and journalling filesystems

[Dan Koren]

Alan Cox wrote:
> 
> > 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.

You're understimating it... :)

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

Quite the contrary. The fewer disk spindles on a system, the
greater the performance gains from XFS' very sophisticated
i/o scheduling. In addition, XFS code is layered neatly
enough that unwanted features/options can be left out if
one so wants.

thx,


Dan Koren                                        Dan.Koren@sgi.com
Engineering Manager, File Systems        phone: (USA) 650-933-3678
Silicon Graphics, Inc.                   pager: (USA) 888-769-0874
1600 Amphiteatre Pkwy. M/S 08U-500       or dkoren_p@pager.sgi.com
Mountain View, CA 94043-1351               fax: (USA) 650-933-3542

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

Re: XFS and journalling filesystems

[Ralf Baechle]

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/

Re: XFS and journalling filesystems

[Dan Koren]

"David S. Miller" wrote:
> 
>    Date:        Tue, 01 Jun 1999 02:15:17 -0700
>    From: Dan Koren <dkoren@cthulhu.engr.sgi.com>
> 
>    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!
> 
> There are third world countries where Linux is used heavily where a
> 486 with 16MB of ram is a "big computer".  These concerns are by no
> means out of date at all.

Even at 16 MB the extra 100 kB or so taken by XFS will have no
visible effect on the system's performance. On the other hand the
performance, and more important the reliability, gained by using
XFS will make a very big difference.

thx,


Dan Koren                                        Dan.Koren@sgi.com
Engineering Manager, File Systems        phone: (USA) 650-933-3678
Silicon Graphics, Inc.                   pager: (USA) 888-769-0874
1600 Amphiteatre Pkwy. M/S 08U-500       or dkoren_p@pager.sgi.com
Mountain View, CA 94043-1351               fax: (USA) 650-933-3542

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

Re: XFS and journalling filesystems

[Stephen C. Tweedie]

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

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