From: "Stephen C. Tweedie" Newsgroups: mail.linux-kernel Subject: Re: [was: ext2 question] XFS opensourced! Date: 28 May 1999 20:29:51 -0700 Organization: redhat.com Lines: 20 Sender: root@fido.engr.sgi.com Approved: mailnews@fido.engr.sgi.com Distribution: sgi Message-ID: <7inmvf$gns3f@fido.engr.sgi.com> References: NNTP-Posting-Host: fido.engr.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Newsgroups: mail.linux-kernel Hi, On Thu, 20 May 1999 11:42:49 +0200 (MET DST), David Weinehall said: > Slashdot does have its uses... I read there just a couple of hours ago > that SGI has/intends to opensource XFS. That'd pretty much solve our need > for a fast Journaling filesystem, I think. Yes, _if_ it comes out as GPL and if it gets integrated well into Linux. XFS is extremely scalable. It will be interesting to see how it compares to ext2/ext3 for smaller filesystems: ext2 is very lightweight indeed as filesystems go. --Stephen From: "Stephen C. Tweedie" Newsgroups: mail.linux-kernel Subject: Re: SGI's XFS DONATED AS OPEN SOURCE!!!!!!!!! Date: 31 May 1999 19:57:47 -0700 Organization: redhat.com Lines: 18 Sender: root@fido.engr.sgi.com Approved: mailnews@fido.engr.sgi.com Distribution: sgi Message-ID: <7ivi7b$hf0dr@fido.engr.sgi.com> References: <19990523213751.K176@bug.ucw.cz> NNTP-Posting-Host: fido.engr.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 From: "Stephen C. Tweedie" Newsgroups: mail.linux-kernel Subject: Re: XFS and journalling filesystems Date: 1 Jun 1999 16:26:40 -0700 Organization: redhat.com Lines: 29 Sender: root@fido.engr.sgi.com Approved: mailnews@fido.engr.sgi.com Distribution: sgi Message-ID: <7j1q7g$i9jkl@fido.engr.sgi.com> References: <199905281458.JAA62562@fsgi344.cray.com> NNTP-Posting-Host: fido.engr.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi, On Tue, 01 Jun 1999 02:06:09 -0700, Dan Koren said: > This is not a problem in page cache systems like Irix, Solaris or > SVR4 (UnixWare). and in Linux. The fact that there is a buffer cache used for some parts of the write path doesn't stop us keeping the page cache consistent at all times. In 2.3, the two paths will use the same memory anyway. > 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. Agreed, that's what is required by Unix file semantics. The cache-to-disk synchronisation semantics are much more relaxed. Lazy batching of the metadata transactions on disk is perfectly legal on Unix. --Stephen From: "Stephen C. Tweedie" Newsgroups: mail.linux-kernel Subject: Re: XFS and journalling filesystems Date: 31 May 1999 19:07:57 -0700 Organization: redhat.com Lines: 35 Sender: root@fido.engr.sgi.com Approved: mailnews@fido.engr.sgi.com Distribution: sgi Message-ID: <7ivf9t$h9gef@fido.engr.sgi.com> References: <199905281653.LAA61598@fsgi344.cray.com> NNTP-Posting-Host: fido.engr.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi, On Fri, 28 May 1999 13:25:33 -0600, "Jeff Merkey" 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 From: "Stephen C. Tweedie" Newsgroups: mail.linux-kernel Subject: Re: XFS and journalling filesystems Date: 1 Jun 1999 16:49:04 -0700 Organization: redhat.com Lines: 25 Sender: root@fido.engr.sgi.com Approved: mailnews@fido.engr.sgi.com Distribution: sgi Message-ID: <7j1rhg$id8jp@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 Hi, On Tue, 01 Jun 1999 02:15:17 -0700, Dan Koren said: >> 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! The size of the active code paths and their impact on the working set in cpu L1 cache is still significant even on today's systems. Every cache miss you introduce to the primary filesystem code paths hurts, whether it's a data cache or an instruction cache miss. --Stephen