NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/benchmar/1661

Internet Message Format | 1992-11-11 | 6.1 KB

Xref: sparky comp.benchmarks:1661 comp.arch.storage:764
Path: sparky!uunet!cbmvax!jesup
From: [e-mail] (Randell Jesup)
Newsgroups: comp.benchmarks,comp.arch.storage
Subject: Re: Disk performance issues, was IDE vs SCSI-2 using iozone
Message-ID: <[e-mail]>
Date: 12 Nov 92 07:59:30 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (Randell Jesup)
Organization: Commodore, West Chester, PA
Lines: 111

[e-mail] (John Bass) writes:
>Take the following track layout, where each group is a cyl of 5 heads, and
>the current head position is on the second group, shown as wraparound linear:
>(Req is queued request, Free is free block, Last is just completed request)

<deleted figure with 7 requests for a 4-cylinder area of disk queued, all
 scattered>

>Short Track (1-3) seeks are under 1.00ms with no settling time (not a stepper).

>Common wisdom would be to service with C-SCAN, as 12/0/1, 12/3/14, 13/0/12,
>13/1/2, 13/4/10, 10/0/8, 10/3/4, and 11/2/6 consuming 5.5 revs and 91ms.
>
>With a rotationally sensitive filesystem and driver, minimal service time
>would be the path 13/1/2, 10/3/4, 11/2/6, 10/0/8, 13/4/10, 13/0/12, 12/3/14,
>then 12/0/1 as 1.2 revs and 20ms.

    Sounds like the old IPI vs SCSI arguments over whether smart or dumb
controllers are better (which is perhaps very similar to our current
discussion, with a few caveats).

    I would suggest (a) that's a highly contrived example, especially for
the desktop machines that all IDE and most SCSI drives are designed for, (b)
both C-SCAN and most other disksorting algorithms have tradeoffs for the
increase in total-system throughput and decrease in worst-case performance;
FCFS actually performs quite well in actual use (I have some old comp.arch
articles discussing this if people want to see them).  The tradeoffs are
usually in fairness, response time, and average performance (no straight
disksort will help you until 3 requests are queued in the first place).  (c)
Your example also depends on very fast track-to-track stepping times AND
very high locality of the requests (within your fast stepping distance), and
becomes less relevant on drives with large numbers of cylinders and fast
spin times.

    For most desktop machines, even if we ignore single-tasking OS's,
probably 99.44% of the time when disk requests occur there are no other
currently active requests.

>In addition, if the filesystem were then presented with storing a 9K
>file it would use 12/3/4 to 12/3/12 (best fit nearest active region).
>A big win over using 10/0/[2,5,8], 10/3/[4,8], 10/4/6-7, and 11/0/8 as
>convential filesystem with a bitmap would tend to allocate.

    Any best-fit will produce better read and rewrite performance over
a first-fit, bitmapped or not, at the potential cost of increased fragmentation
and slower block allocation (especially if the bitmap or free-list isn't all
kept in memory at once).

>I think that zoned recording is great ... and geometry hiding is bad.
>Most zoned drives do not CURRENTLY allow for the option of turning
>off the mapping.

    Do you mean IDE or SCSI?  SCSI drives allow you to ask about the
mapping via Mode Sense pages.  No problem.

>  If more filesystems and drivers used positional clues
>and could handle variable track lengths, it would be a minor firmware
>issue to have a direct mode. I don't see this as a significant problem,
>certainly any mfgr could spec such a requirement as part of purchase at
>near zero cost per unit.

    And large cost in software for close to NIL gain.  For "big"
(real multi-user) machines, this might well be some amount of gain, though
I'm still doubtful about whether it would be worth the trouble.  For "disk
farms", it's a good bet it's worth trying tricks like this.  Not for desktops.
I also have my doubts about your "zero cost" statement...

>IDE drives should support the WD1010 SCAN_ID command allowing the driver
>locate current head position ... no such SCSI feature exists.

    No such IDE feature exists.  This _was_ a discussion of IDE vs. SCSI.
As far as I know, no one has even proposed such a feature to the CAM-ATA
committee, let alone implemented it.  The only positional information is the
index bit in the status register (I suspect many drives just leave it 0).

>Additional issues are control of sector skewing to facilitate head/cyl
>switching and group/request interleave factors ... Low Level format ability is
>very important when the drive makes the wrong choices as defaults ... again
>any volume system vendor can request optimal layouts at minimal per unit costs.

    Low-level formatting on some (many?) modern drives can't be done
outside a factory ("format" just does logical formatting).  Some totally
ignore format requests.

>Given 1974-1986 hardware, most of the current filesystem design issues
>were correct .... to just OK. Given 1992-1995 hardware, the same tradeoffs
>are mostly WRONG. Performance comes by DESIGN, not tuning, selection, or
>non-reflective evolution. Too much performance engineering is making do with
>existing poor designs ...  instead of designing how it should be.

    While your statement is correct, I think you're guilty here also.
Just because method/hack/whatever was a good choice for V7 Unix running RPS
drives, doesn't mean that that approach is (as) effective today.  Technologies
change, performance/cost ratios change, etc.  I also think your opinions
come from a large, heavy-io multi-user systems background; which while
interesting for those working with such systems is pretty irrelevant to
the desktop systems that IDE and (most of) SCSI are designed for.

>I make my living re-evaluating other peoples past design decisions with
>today's constraints ... most people learn/remember only the solutions (how's)
>...  it's much more important to learn/explore the issues (why's)!

    Quite true.  Don't forget to re-evaluate your own every so often,
though.

--
To be or not to be = 0xff
-
Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, [e-mail]  BIX: rjesup
Disclaimer: Nothing I say is anything other than my personal opinion.