Re: XFS and journalling filesystems

Jim Mostek (mostek@sgi.com)
Thu, 27 May 1999 12:44:17 -0500 (CDT)

>
>
>----- Original Message -----
>From: Andreas Bogk <andreas@andreas.org>
>To: Jeff Merkey <jmerkey@timpanogas.com>
>Cc: <linux-kernel@vger.rutgers.edu>
>Sent: Tuesday, May 25, 1999 10:37 AM
>Subject: Re: XFS and journalling filesystems
>
>
>> "Jeff Merkey" <jmerkey@timpanogas.com> writes:
>>
>> > 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
>>
>> This may be true for some implementations, but not XFS. It uses
>> multiple trees for FS resource management, so every CPU can just grab
>> one of the trees and go ahead. SGI does have some nice SMP machines,
>> and they are aware of the problems with that.
>>
>
>Sorry, I've been doing SMP for about 12 years, and it isn't this simple.
>Grabs "one of the trees". What happens if they are sharing open files or
>two processors try to share the tree? Linux doesn't have decent shared sync
>objects, how do they implement r/w locks, do they provide them in the file
>system, or does Irix have its own unique ones? The log file (journal is

XFS has it's own locks throughout for various things. There is an inode lock,
an io lock, various locks in the log, buffer locks, ... XFS doesn't really
depend on locks outside the FS (like a system wide kernel_lock or io_lock).
XFS is fully re-entrant. You should see xfs_rename!

>SINGLE threaded [it has to be on a journalling file system]). There's a lot

Very few parts of XFS are single threaded. These critical regions are pretty
limited.

>of issues with mapping a **REAL** SMP file system to Linux. Linux needs a
>lot of SMP work to support these types of technologies with some decent
>scaling and an expanded set of sync primitive. I've got $100.00 that says
>it will be **SLOWER** than ext2, and the scaling will be dismal. Care to
>take the bet?

hmmm. I'm not a betting man. The performance of XFS will depend on lots
of trade-offs.

Jim

>
>Jeff
>
>> > 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.
>>
>> As long as SGI shows neither code nor license, this point is moot
>> anyways. But XFS scores pretty well for a jounaling file system, or
>> just about any Unix file system currently available.
>>
>
>Let's see if their lawyers are really going to let them give away their IP
>with no strings attached. This will be interesting.
>
>
>Jeff
>
>
>> 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/