Date: Mon, 28 Oct 2002 20:24:15 -0800 From: Peter Wemm <peter@wemm.org> To: "Daniel O'Connor" <doconnor@gsoft.com.au> Cc: Chuck Robey <chuckr@chuckr.org>, Kenneth Culver <culverk@yumyumyum.org>, "Wilkinson, Alex" <Alex.Wilkinson@dsto.defence.gov.au>, hackers@FreeBSD.ORG Subject: Re: [hardware] Tagged Command Queuing or Larger Cache ? Message-ID: <20021029042415.967662A88D@canning.wemm.org> In-Reply-To: <1035861964.77698.83.camel@chowder.localdomain>
next in thread | previous in thread | raw e-mail | index | archive | help
"Daniel O'Connor" wrote: > On Tue, 2002-10-29 at 02:40, Chuck Robey wrote: > > > Personally I find that no HD manufacturer has a good reputation - they > > > have all made trashy drives at one point. Give the general time it takes > > > for problems to surface vs product lifetimes makes deciding what to buy > > > a PITA :( > > > > No, I'd take issue with that, hitting on all HD mfrs in general, it has > > more to do with the technology, and the focus of the market it's aimed at. > > In general, SCSI drives have a far better rep than the IDE drives. That > > probably has to do with the market sector they focus on. With one > > exception (a heat problem I probably must blame on myself doing some > > learning) I've had no problems with scsi drives, and I beat hell out of > > them. > > They sure do have a better rep. but they DO cost 4x as much :) > (Not including a controller) > > > I guess if you *must* run IDE, then run raid arrays. If you don't run > > either, then you can't complain if you buy the cheapest and don't get the > > best reliability. > > Indeed, though in general I find it pretty hard to justify SCSI prices > in the particular application we have. A seperate parallel thread is running on -alpha (bad!), where the question of whether tagged queueing on IDE was safe or not. === (I wrote:) Peter Jeremy wrote: > 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 sad 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. === Personally, I find that the sub-5ms seek time on scsi drives contributes a fair bit to the percieved speed of the box under load. Without serious load though, it is very hard to tell the difference between scsi and ide. Most of the recent scsi drives I've used are between about 4.1ms through 4.5ms seek vs ide drives at between 8ms and 12ms seek time. What IDE calls 'tagged queueing' seems to be little more than allowing ide drives to release the bus while they go and do something. It dramatically improves the bus contention when you have a pair of drives on a single ide channel.. almost to the point that there is little or no degradation when you are hammering both drives at once. 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-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021029042415.967662A88D>