Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!usc!apple!rutgers!mephisto!udel!haven!ncifcrf!lhc!usenet
From: usenet@nlm.nih.gov (usenet news poster)
Newsgroups: comp.arch
Subject: Re: disk rotation speed
Keywords: multiple heads, databases
Message-ID: <1990Aug4.014643.6274@nlm.nih.gov>
Date: 4 Aug 90 01:46:43 GMT
References: <2635@mindlink.UUCP> <10048@pt.cs.cmu.edu> <1990Jul31.200043.5189@nlm.nih.gov> <1990Aug1.220440.20727@ico.isc.com> <WAYNE.90Aug2143750@dsndata.uucp>
Reply-To: states@tech.NLM.NIH.GOV (David States)
Organization: National Library of Medicine, Bethesda, Md.
Lines: 43

|> rcd@ico.isc.com (Dick Dunn) writes:
|> [ ... ] In fact, you can see some high-end drives
|> designed with dual actuators to reduce rotational latency...the tradeoff
|> here is that it was apparently cheaper to add a second set of heads, servo,
|> r/w logic and all, than to deal with the problems of faster rotation.

>wayne@dsndata.uucp (Wayne Schlitt) writes:
>I have wondered about this for a long time.  Are there many drives
>with more than one actuators?  Why arent there more?
>
>I would think that this would not only reduce the rotational latency,
>but it could also do a lot to reduce the seek time.  Depending on the
>smarts in the disk controller, this could make a big increase in real
>throughput.  In the not so uncommon case of copying a file from one
>place on the disk to another location, you could have one actuator
>sitting and reading while the other one is doing the writing.
>Poof-da, zero seek time and possible zero rotational delay.

Cache busting relational databases would be another big win for this
scheme.  Instead of sending one head skittering all over the disk to
pick up bits of the different tables as they are needed, in and ideal
system you would have one head per table.  Some implementations effectively
do this by splitting the database across multiple disks with one table per
disk, but unless you need the space, it seems wasteful.  Having all the 
data on one disk would allow more flexibility in scheduling when the number
of seek requests exceded the number of available heads.

>Yeah, I know, you would have to either have two data paths to the
>disk or one data path that was quick real quick and a buffer so that
>you could keep both heads busy.  You would also have to have a fast
>processor in order to keep the data flowing through quick enough to
>have zero rotational delay, but still, I could see this as a big win.

If you take the "data transfer rates are the limiting factor in disk
design" arguement to its logical extreme, then instead of adding more
platters to increase disk capacity, you should slow the rotation rate
and add more heads.  Slower rotation at the same transfer rate ->
higher density, more heads -> same average latency and more flexible
scheduling.

>-wayne

David States