Date: Thu, 2 Nov 2000 19:39:09 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: Marius Bendiksen <mbendiks@eunet.no> Cc: Alfred Perlstein <bright@wintelcom.net>, Randell Jesup <rjesup@wgate.com>, arch@freebsd.org Subject: Re: Like to commit my diskprep Message-ID: <200011030339.eA33d9D43976@earth.backplane.com> References: <Pine.BSF.4.05.10011030209060.14073-100000@login-1.eunet.no>
next in thread | previous in thread | raw e-mail | index | archive | help
: :> 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. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011030339.eA33d9D43976>