From owner-freebsd-alpha Mon Oct 28 19: 5:39 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 A3DE437B401 for ; Mon, 28 Oct 2002 19:05:37 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3DC443E42 for ; Mon, 28 Oct 2002 19:05:29 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 873BF2A88D; Mon, 28 Oct 2002 19:05:29 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Peter Jeremy Cc: "Wilkinson,Alex" , alpha@FreeBSD.ORG Subject: Re: [hardware] Tagged Command Queuing or Larger Cache ? In-Reply-To: <20021029020943.GI6446@gsmx07.alcatel.com.au> Date: Mon, 28 Oct 2002 19:05:29 -0800 From: Peter Wemm Message-Id: <20021029030529.873BF2A88D@canning.wemm.org> 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 Peter Jeremy wrote: > On 2002-Oct-29 09:55:49 +1030, "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 ? > > This is somewhat off-topic for -alpha... > > The quick answer is: "Not if you value your data". > > The longer answer is: Without tagged queueing, the device driver > cannot determine when the data for a particular write command has been > committed to the media (as against just being stored in the cache). > Soft-updates (in particular) relies on accurate write ordering to > ensure that the filesystem on disk is always consistent. Having a > volatile cache in the disk breaks this assumption - if you have a > power failure, you don't know what was lost. > > The safe states are: tagging & caching or no-caching (which is slow). Actually, not even then. Modern IDE drives only write entire tracks at a time. If you modify a single sector, then the drive has to read the entire track into the buffer, in-place edit the sector, and then rewrite the entire track. As you can imagine, this violates the basic assumptions of FFS and softdep. They assume that only sectors that are written to are at risk, and do all their ordering based on that assumption. But the assumption is completely bogus. Even with no-caching it doesn't work because if the drive loses power after only having written half of the track, then you risk losing the rest - the track is written from "wherever", and not any index marks. ie: the track is just as likely to overwrite the second half of the sectors first, and when you lose power, you have two copies of the first half of the sectors. Basically you have to assume that the entire track and all of the nearby sectors could get lost or trashed. And that completely blows FFS's assumptions out of the water. And what is worse, is that many SCSI disks are similar these days. But not all of them (I'm told). Basically if you get a power failure, you are totally screwed. softdep will save you from a hard OS level lockup/reset though. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message