Date: Mon, 28 Oct 2002 19:05:29 -0800 From: Peter Wemm <peter@wemm.org> To: Peter Jeremy <peter.jeremy@alcatel.com.au> Cc: "Wilkinson,Alex" <Alex.Wilkinson@dsto.defence.gov.au>, alpha@FreeBSD.ORG Subject: Re: [hardware] Tagged Command Queuing or Larger Cache ? Message-ID: <20021029030529.873BF2A88D@canning.wemm.org> In-Reply-To: <20021029020943.GI6446@gsmx07.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Jeremy wrote:
> On 2002-Oct-29 09:55:49 +1030, "Wilkinson,Alex" <Alex.Wilkinson@dsto.defence.
gov.au> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021029030529.873BF2A88D>