From owner-freebsd-arch Fri Nov 3 6:58:21 2000 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 5AD1737B4CF for ; Fri, 3 Nov 2000 06:58:15 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id GAA06927; Fri, 3 Nov 2000 06:58:00 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda06925; Fri Nov 3 06:57:51 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.0/8.9.1) id eA3EvpH12734; Fri, 3 Nov 2000 06:57:51 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdS12725; Fri Nov 3 06:57:40 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.1/8.9.1) id eA3Evdr39709; Fri, 3 Nov 2000 06:57:39 -0800 (PST) Message-Id: <200011031457.eA3Evdr39709@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpde39702; Fri Nov 3 06:56:54 2000 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.1.1-RELEASE X-Sender: cy To: Matt Dillon Cc: Marius Bendiksen , Alfred Perlstein , Randell Jesup , arch@FreeBSD.ORG Subject: Re: Like to commit my diskprep In-reply-to: Your message of "Thu, 02 Nov 2000 19:39:09 PST." <200011030339.eA33d9D43976@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 03 Nov 2000 06:56:53 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200011030339.eA33d9D43976@earth.backplane.com>, Matt Dillon writes: > > : > :> Indirect blocks aren't relevant if you are using a large block size, > :> because there are few enough of them the OS has no problem caching > :> them. > : > :The problem is related to highly random access, as the indirect blocks > :will tend to get pushed out of the cache on occasion, requiring multiple > :seeks when the file is being accessed. Using extents will solve this. > : > :> 32K block size 4MB > : > :Note that these 4MB are better spent on caching real data than they are on > :compensating for the absence of extents in the FFS inode. > :.. > : > :> It becomes somewhat more of an issue for a terrabyte-sized database, > :> but still no biggy considering the memory you can get these days. > : > :I reiterate the above point. The kind of memory in question here is really > :way over the top, compared to the 8/16 bytes required to hold an extent > :reference and the bit to indicate that the inode uses such. > : > :Marius > > Lets put things into perspective here. You have a multi-gig or terrabyte > database, and that pretty much means you have to at least a gig of ram > in the machine that's going to be accessing it. Otherwise why bother > with caching at all? > > If you have a machine with a gig of ram, losing 4MB is REALLY not a big > deal. Assuming an Oracle database of that size, you probably want at least 12-16 GB of memory with 80% of it used for SGA. I would think that most other DBMS's would have the same features and requirements. The Veritas filesystem (vxfs) has an option to turn of caching for for a specified filesystem. Otherwise Oracle would cache in the SGA and the filesystem would cache as well. Prior to this, performance wise, you'd be better off using raw slices. The ability to turn of caching of data, while still caching metadata, would be a good mount or tunefs option for applications that perform their own caching, e.g. Oracle. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message