From: Dan Koren <dkoren@cthulhu.engr.sgi.com>
Newsgroups: mail.linux-kernel
Subject: Re: SGI's XFS DONATED AS OPEN SOURCE!!!!!!!!!
Date: 1 Jun 1999 14:14:20 -0700
Organization: Silicon Graphics Computer Systems
Lines: 38
Sender: root@fido.engr.sgi.com
Approved: mailnews@fido.engr.sgi.com
Distribution: sgi
Message-ID: <7j1ifc$i98h6@fido.engr.sgi.com>
References: <19990523213751.K176@bug.ucw.cz> <199905271735.MAA55324@fsgi344.cray.com> <14163.9696.18361.367035@dukat.scot.redhat.com> <3753AEE9.AB89F30D@engr.sgi.com> <19990601211144.A5032@ce.chalmers.se>
Reply-To: Dan.Koren@sgi.com
NNTP-Posting-Host: fido.engr.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Fredrik Lundholm wrote:
>
> Hello,
>
> > changes we might be making for XFS. Note however that XFS itself
> > is not part of the kernel but rather a loadable module. The terms
>
> Well, to be able to claim all that good-will that steams from words
> like donation and open-source,
> I really hope the module will be released in SOURCE form.
> A binary module doesn't strike me as particulary exiting nor flexible
> enough to gain required momentum..
>
> /Fredrik Lundholm
> exce7@ce.chalmers.se
As our press announcement said, XFS will be released in open source.
That does not contradict/preclude its being structured as a loadable
module. XFS is a pretty large file system (100k+ lines of code) and
it wouldn't be reasonable for something that large to be statically
linked with the kernel, as there are probably lots of applications
and configurations that don't need its capabilities.
I hope this clarifies things.
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/
From: Dan Koren <dkoren@cthulhu.engr.sgi.com>
Newsgroups: mail.linux-kernel
Subject: Re: SGI's XFS DONATED AS OPEN SOURCE!!!!!!!!!
Date: 1 Jun 1999 01:55:48 -0700
Organization: Silicon Graphics Computer Systems
Lines: 32
Sender: root@fido.engr.sgi.com
Approved: mailnews@fido.engr.sgi.com
Distribution: sgi
Message-ID: <7j076k$hu93v@fido.engr.sgi.com>
References: <3744398B.97F05A49@icai.upco.es> <19990523213751.K176@bug.ucw.cz>
Reply-To: Dan.Koren@sgi.com
NNTP-Posting-Host: fido.engr.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Pavel Machek wrote:
>
> 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.
File system companies like Transarc or Veritas could not exist if
such were the case. File systems can be ported between different
OS's, even though this isn't trivial. Developing a transactional
file system from scratch is still a lot more work than porting an
existing one.
> (Or maybe SGI is going to do work for us?)
SGI is porting XFS to Linux.
> There are some non-trivial issues buffer cache.
Indeed :)
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/
From: Dan Koren <dkoren@cthulhu.engr.sgi.com>
Newsgroups: mail.linux-kernel
Subject: Re: SGI's XFS DONATED AS OPEN SOURCE!!!!!!!!!
Date: 1 Jun 1999 03:13:57 -0700
Organization: Silicon Graphics Computer Systems
Lines: 35
Sender: root@fido.engr.sgi.com
Approved: mailnews@fido.engr.sgi.com
Distribution: sgi
Message-ID: <7j0bp5$i2aoq@fido.engr.sgi.com>
References: <19990523213751.K176@bug.ucw.cz>
Reply-To: Dan.Koren@sgi.com
NNTP-Posting-Host: fido.engr.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
"Stephen C. Tweedie" wrote:
>
> 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
All the development that SGI is doing on the Linux kernel will be
released under GPL, and that includes page cache and buffer cache
changes we might be making for XFS. Note however that XFS itself
is not part of the kernel but rather a loadable module. The terms
of the XFS license are still being reviewed by our legal staff.
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/
From: Dan Koren <dkoren@cthulhu.engr.sgi.com>
Newsgroups: mail.linux-kernel
Subject: Re: XFS and journalling filesystems
Date: 1 Jun 1999 02:13:19 -0700
Organization: Silicon Graphics Computer Systems
Lines: 36
Sender: root@fido.engr.sgi.com
Approved: mailnews@fido.engr.sgi.com
Distribution: sgi
Message-ID: <7j087f$htg4q@fido.engr.sgi.com>
References: <199905281458.JAA62562@fsgi344.cray.com> <008201bea924$aee5b8c0$e6976dcf@TRGMERKEYNT2000>
Reply-To: Dan.Koren@sgi.com
NNTP-Posting-Host: fido.engr.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Jeff Merkey wrote:
>
> 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 is not a problem in page cache systems like Irix, Solaris or
SVR4 (UnixWare). 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. Also note that certain
OS's do read/write serialization in the VFS layer anyway, quite
independently of what file systms do underneath (I believe SVR4
and Solaris behave this way).
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/
From: Dan Koren <dkoren@cthulhu.engr.sgi.com>
Newsgroups: mail.linux-kernel
Subject: Re: XFS and journalling filesystems
Date: 29 May 1999 10:29:21 -0700
Organization: Silicon Graphics Computer Systems
Lines: 35
Sender: root@fido.engr.sgi.com
Approved: mailnews@fido.engr.sgi.com
Distribution: sgi
Message-ID: <7ip85h$h3tmh@fido.engr.sgi.com>
References: <E10m0gq-0000pk-00@the-village.bc.nu>
Reply-To: Dan.Koren@sgi.com
NNTP-Posting-Host: fido.engr.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
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/
From: Dan Koren <dkoren@cthulhu.engr.sgi.com>
Newsgroups: mail.linux-kernel
Subject: Re: XFS and journalling filesystems
Date: 1 Jun 1999 03:37:10 -0700
Organization: Silicon Graphics Computer Systems
Lines: 31
Sender: root@fido.engr.sgi.com
Approved: mailnews@fido.engr.sgi.com
Distribution: sgi
Message-ID: <7j0d4m$i2etq@fido.engr.sgi.com>
References: <76D8782817C5D211A37400104B0C84B029C52F@nz-wlg-exch-1.nz.unisys.com> <3753A4A5.C2A4FE91@engr.sgi.com> <199906010928.CAA04308@pizda.davem.net>
Reply-To: Dan.Koren@sgi.com
NNTP-Posting-Host: fido.engr.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
"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/
From: Dan Koren <dkoren@cthulhu.engr.sgi.com>
Newsgroups: mail.linux-kernel
Subject: Re: XFS and journalling filesystems
Date: 1 Jun 1999 19:24:36 -0700
Organization: Silicon Graphics Computer Systems
Lines: 39
Sender: root@fido.engr.sgi.com
Approved: mailnews@fido.engr.sgi.com
Distribution: sgi
Message-ID: <7j24l4$ifjk0@fido.engr.sgi.com>
References: <76D8782817C5D211A37400104B0C84B029C52F@nz-wlg-exch-1.nz.unisys.com> <3753A4A5.C2A4FE91@engr.sgi.com> <199906010928.CAA04308@pizda.davem.net>
Reply-To: Dan.Koren@sgi.com
NNTP-Posting-Host: fido.engr.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
"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.
We are well aware of that, and we will of course make every effort
possible (short of a complete redesign) to restructure the code to
have the smallest possible footprint, and to make it modular so that
it can be configured according to the needs of the application and
the available hardware configuration.
That being said it must also be noted that the main focus of the
original XFS design was systems with large amounts of main memory
and large numbers of disk spindles. This doesn't make it incapable
of running on smaller systems, but as with everything else there
will be a point of diminishing returns or some size where it just
won't fit.
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
From: Dan Koren <dkoren@cthulhu.engr.sgi.com>
Newsgroups: mail.linux-kernel
Subject: Re: XFS and journalling filesystems
Date: 1 Jun 1999 02:29:55 -0700
Organization: Silicon Graphics Computer Systems
Lines: 43
Sender: root@fido.engr.sgi.com
Approved: mailnews@fido.engr.sgi.com
Distribution: sgi
Message-ID: <7j096j$i40us@fido.engr.sgi.com>
References: <76D8782817C5D211A37400104B0C84B029C52F@nz-wlg-exch-1.nz.unisys.com>
Reply-To: Dan.Koren@sgi.com
NNTP-Posting-Host: fido.engr.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
"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>
>
> 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 :)].
>
> 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!
When we started VxFS development at Veritas in 1990 under contract
to AT&T Bell Labs, one of the design goals/constraints was that it
should be able to run on machines with 4 MB memory. But by the time
we finished release 1.0 one year or so later, the smallest machine
one could buy already had 8 MB memory. Using another 100kB or so of
kernel memory for a good quality file system is a very reasonable
tradeoff. Or would you rather save 100 kB memory and have a file
system that takes 5, 10 or 20 minutes to recover after a crash?
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
![[BACK]](/icons/back.gif){kind=icon}
Return to dan-koren.txt CVS log ![[TXT]](/icons/text.gif){kind=icon}
![[DIR]](/icons/dir.gif){kind=icon}
Up to [Development] / xfs-website.orig / postings