From owner-freebsd-alpha Mon Oct 28 22:54:43 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8533537B401 for ; Mon, 28 Oct 2002 22:54:42 -0800 (PST) Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3026D43E42 for ; Mon, 28 Oct 2002 22:54:42 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0225.cvx40-bradley.dialup.earthlink.net ([216.244.42.225] helo=mindspring.com) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 186QGt-0006ey-00; Mon, 28 Oct 2002 22:54:39 -0800 Message-ID: <3DBE3062.30F317A2@mindspring.com> Date: Mon, 28 Oct 2002 22:53:22 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alex.Wilkinson@dsto.defence.gov.au Cc: alpha@freebsd.org Subject: Re: [hardware] Tagged Command Queuing or Larger Cache ? References: <20021029095516.G91719-100000@squirm.dsto.defence.gov.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org "Wilkinson,Alex" wrote: > Do the benifits from a having a larger disk cache such as the "WD 40GB > 7200RPM w/8MB Cache" has, outweigh the benefits of Tagged Command > Queuing ? No. You have to turn off write caching, or guarantee that the write request is not indicated as completed to the disk controller until the write has been committed to stable storage, if you want it to be reliable. Therefore, you don't get significant speed of of a larger cache, unless you are doing a lot of random reading, with little or no writes (e.g. noatime or mounted read-only, so that metadata is not written as a result of the random reads). In general, you are screwed anyway, for reasons noted elsewhere this thread by Peter Wemm. What you need is a logging FS that logs whole tracks at a time, which means that it needs to know the physical geometry of the disk, so that it knows where individual track boundaries are; this is mode page 2 in SCSI; I don't think you can get this data from an IDE drive, which is going to claim that it's real geometry is the same as its fictitious geometry, even when you confront it and call it a liar to its face. It's going to be a lot of work, and by the time you are done doing it, the disk manufacturers will have done something new and stupid to make the hardware unreliable, even in the face of this type of software workaround to their existing stupidty. Have fun with it, though... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message