[TUHS] Disk data layout (was: /dev/drum)

[Greg 'groggy' Lehey]

On Monday, 23 April 2018 at 17:30:24 -0600, Grant Taylor via TUHS wrote:
> On 04/23/2018 04:15 PM, Warner Losh wrote:
>> It's weird. These days lower LBAs perform better on spinning
>> drives.  We're seeing about 1.5x better performance on the first
>> 30% of a drive than on the last 30%, at least for read speeds for
>> video streaming....

This relates to modern disks, of course, where there are different
amounts of data on each track.  Until about 1990 each track had a
constant amount of data on it.

> I think manufacturers have switched things around on us.  I'm used
> to higher LBA numbers being on the outside of the disk.  But I've
> seen anecdotal indicators that the opposite is now true.

"LBA" is newer than the time we're talking of.  In those days, disk
data was addressed physically, by cylinder, head and sector, terms
that only died out round the turn of the century.  I was heavily
involved in disk data recovery in the 1980s, and I know beyond any
doubt that cylinder 0 was on the outside (closest to where the heads
retracted before changing a pack).  I was amazed when I discovered
that CD-ROMs started counting from the inside.

But how do I prove it?  I've done some net trawling and looking
through my pile of junk here, but I can't find anything convincing.
http://www.datadoctor.biz/data_recovery_programming_book_chapter2-page16.html
shows a layout like this, and also the statement

   The tracks are numbered, starting from 0, starting at the outside
   of the platter and increasing as you go in.

But by itself that's not overly convincing.  I looked at the manual
for the IBM 3330, but I couldn't find anything specific.  Does anybody
else have any useful reference?

Of course, you can map CHS to LBA in multiple ways, and conceivably it
has been done differently.

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180425/e630b720/attachment.sig>