From: Dan Koren 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 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 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 > 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 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 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: 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 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 > > 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 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 > > 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 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). 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). > > 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