From owner-freebsd-hackers Sun Jan 26 11:31:15 2003 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 40E7037B401 for ; Sun, 26 Jan 2003 11:31:14 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDD5B43E4A for ; Sun, 26 Jan 2003 11:31:13 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0QJVC0i052102; Sun, 26 Jan 2003 11:31:12 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0QJVCp8052101; Sun, 26 Jan 2003 11:31:12 -0800 (PST) Date: Sun, 26 Jan 2003 11:31:12 -0800 (PST) From: Matthew Dillon Message-Id: <200301261931.h0QJVCp8052101@apollo.backplane.com> To: "Sean Hamilton" Cc: Subject: Re: Random disk cache expiry References: <000501c2c4dd$f43ed450$16e306cf@slugabed.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :Greetings, : :I have a situation where I am reading large quantities of data from disk :sequentially. The problem is that as the data is read, the oldest cached :blocks are thrown away in favor of new ones. When I start re-reading data :from the beginning, it has to read the entire file from disk again. Is there :some sort of sysctl which could be changed to induce a more random expiry of :cached disk blocks? Wouldn't it seem logical to have something like this in :place at all times? : :thanks, : :sh Hi Sean. I've wanted to have a random-disk-cache-expiration feature for a long time. We do not have one now. We do have mechanisms in place to reduce the impact of sequential cycling a large dataset so it does not totally destroy unrelated cached data. Due to the way our page queues work, it's not an easy problem to solve. You might be able to simulate more proactive cache control by using O_DIRECT reads for some of the data, and normal reads for the rest of the data (see the 'fcntl' manual page). But it might be better simply to purchase more memory, purchase a faster hard drive, or stripe two hard drives together. HDs these days can do 25-50MB/s each so striping two together should yield 50-100MB/s of sequential throughput. See the 'STRIPING DISKS' section in 'man tuning'. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message