NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/benchmar/1696

Internet Message Format | 1992-11-15 | 5.7 KB

Xref: sparky comp.benchmarks:1696 comp.arch.storage:776
Path: sparky!uunet!spool.mu.edu!olivea!sgigate!sgi!fido!zola!zuni!anchor!olson
From: [e-mail] (Dave Olson)
Newsgroups: comp.benchmarks,comp.arch.storage
Subject: Re: Disk performance issues, was IDE vs SCSI-2 using iozone
Message-ID: <[e-mail]>
Date: 16 Nov 92 07:53:09 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail] (Net News)
Organization: Silicon Graphics, Inc.  Mountain View, CA
Lines: 101

In <[e-mail]> [e-mail] (John Bass) writes:
| Hi Dave ... long time no hear .... interesting that so many Ex-Fortune
| guys all ended up at SGI ...

Yep (particularly now that we have ex-MIPS folks here also).

| mapping does generate additional unwanted I/O's that the data base
| may not anticipate ... remapping a single sector in the middle of a
| large request will generate 3 I/O's .... start, remaps, and ending segements.

Another reason for not doing it on the host at all.  Newer (read, more
or less high performance) drives tend to have hardware dedicated to the
block translation to sect/head/cyl, etc.  Granted that the drives often
have rather underpowered CPU's for all that they are asked to do, they
usually throw enough hardware at it to overcome the problems.  I'm sure
this isn't the case for most IDE drives though.

| of the cpu. Now sure the SGI machines have faster CPU's/memory, but this
| is not a great tradeoff for 386 PC's.  Some large drives have more than a
| hundred errors.  Now sure, key vendors can order error free drives for a
| premium, but what about the rest of the market?

We certainly don't order error free drives, but we do expect
the drive firmware do handle the errors in an efficient way.  By
and large, they do so.  The older ESDI disk driver handled the
bad blocks in the driver/controller, as did SMD, and the overhead
does add up.

| Even with slip sectoring in the drive, error groups will over run, and
| the drive will do even slower table lookups and/or long seeks. Slip

You've lost me here, unless you are postulating cases where there are
too many defects in a zone to do sector slipping.  Yes, this can
happen, but with as few as 2 spare locations per cylinder, it is quite
rare.  For those who really care, you can simply allocate more spares
per cylinder (at 5 per cylinder, the odds are vanishingly small of having
to seek for most current drives).

| sectoring on scsi drives also makes the math more complex to translate
| logical to physical for every request ... on a slow micro this time adds
| up as well. For an IDE drive that does geometry mapping it is also a problem.

Yes, if the cpu on the drive is doing it all; these days that often isn't
the case, as there is often dedicated hardware to help (again for SCSI).

| >| Nor would I like to be the customer who has his FAT or root inode over
| >| a remapped sector.
| >
| >As I said above, I doubt this would be measurable, given any decent
| >drive.  Of course, there are always going to be poorly implemented
| >drives, but you have to draw the line somewhere.
|
| I'm sorry Dave .... but I have already seen this happen ... the spare in
| the current cyl was already used, and each access to the FAT did two long
| seeks. Of course all that was needed was repartitioning the drive to move
| the FAT .... but still, most customers don't understand the problem.

Or by simply allocating more spares per cylinder.  With only 1 spare you
will occasionally have this kind of problem, for sure.

| Now maybe there are better ways than remapping to the end of the drive ...
| how do current drives handle more than n bad sectors in a zone? Do
| they table lookup on every request?

Presumably.  However, at that point you have a drive that is seriously
sick anyway, and my experience is that once you reach that point, the
drive deteriorates rapidly to the point of complete unusablity.

| For SCSI this is true with tagged queuing ... for IDE and many caching ctlrs
| enabling write behind leaves you entirely blind to the error, and it can be
| more than one request back.

Right.  Then you are definitely making a pretty risk tradeoff for
peformance vs. reliability.  I knew IDE drives had their week spots,
but I didn't realize the design was this flawed.  Controllers that
don't tell you about errors on buffered writes aren't great either.
SCSI drives tell you about errors on buffered writes unconditionally,
but the buffering level is limited to 1 deep because of that.

| Sgi ships top of the line ... including power supplies ... with cheap

I wish.  The power supplies are a lot closer to the ragged edge than
one might hope for at the lower end, particularly on fully loaded
systems.  Still, outright failures are pretty rare.  We did see a
problem where we got 300 mv of ripple on the +12v in one batch of
power supplies, and it caused some flakiness in some systems.  Those
were caught pretty quickly.  Still, your point is taken, most PC
owners probably live with lower quality supplies.

| I agree that for SCSI this represents a gain due to command decode timings
| of typical drives ...  for IDE the amount of overlap is NIL, and not worth
| the implied error risks.

Another couple of cases where we sort of confused each other (all of us
in the discussion) by talking about multiple drive types at the same
time.  Oh well.  You are probably right, we've about beaten this
into the ground!
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   [e-mail]