NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/unix/aux/2899

Internet Message Format | 1992-07-21 | 5.4 KB

Path: sparky!uunet!sun-barr!cs.utexas.edu!usc!rutgers!cmcl2!panix!alexis
From: [e-mail] (Alexis Rosen)
Newsgroups: comp.unix.aux
Subject: Re: LONG ravings about disk geometry. (was: Re: /etc/disktab entry for Quantum LP240S)
Message-ID: <[e-mail]>
Date: 21 Jul 92 08:34:08 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]
Organization: PANIX Public Access Unix, NYC
Lines: 114

[e-mail] (Conrad C. Nobili) writes:
>[e-mail] (Alexis Rosen) wrote:
>> [e-mail] (Conrad C. Nobili) writes:
>> >(Why do these utilities
>> >refer to what is apparently tracks as heads?

>> No idea. Are you sure of that?

>Here I was just referring again to the "nt = heads" wisdom....
>We explain this later of course....  By nt we mean the number
>of tracks per cylinder rather than the number of tracks per
>surface....

Right. All in all, a most unclever way of expressing things.

>> msb= Most Significant Byte. lsb = ...

>Well, of course!  Drool, slobber....  But what is "Cylinders (lsb)"?

Same idea. Whatever that particular utility means by "Cylinders", it's the
least sig. byte. Since large drives such as your HP or our Elite have about
2100 cylinders, you need 16-bit cylinder counts.

>> Hm, the "8 Cylinders" must mean 8 platters. With only 13 heads, and assuming
>> one servo head, I don't know what the other disk would be for. Parity? I
>> don't think that's it...

>Ah, see?  This is exactly the kind of thing that bugs me!
>How *do* we explain that extra platter?

Not my problem. It exists. But what I wrote was right. Maybe the real
explanation is an off-by-one error in your utility?

>> ns is actually number of sectors per track. The Cylinders is the number of
>> tracks on all platters divided by the number of platters.

>Don't you mean "divided by the number of surfaces" there?

Yes. Sorry...

>Cylinders is then the number of tracks per surface.  Fine,
>but the numbers seem rather high, no?  My 3.5" disk has a
>radius of 1.75" -- let's shave a tad off for the hub, say
>0.125", giving a not-very-generous quarter-inch-diameter
>hub -- then 1.625" / 2051 = 0.000792296", and we get track
>separation of about eight ten-thousandths of an inch.  I'm
>very impressed!  Including some inter-track gap, the tracks
>are *very* narrow.  This sort of thing is what led me to
>believe that Cylinders was something more complex than just
>the number of tracks per surface....

Nope. Modern technology, with 3.5" 1GB drives, is very slick. And getting
slicker. BTW, there's not much gap.

>> So the total number of tracks is Heads (13) times Cylinders (2051), or
>> 26663. And the number of sectors per track is therefore Sectors (2054864)
>> divided by Tracks (26663), or 77.068, which (since it must be a whole number)
>> rounds down to 77.

>Yeah, good!  That (77) is the number I had come up with too,
>but I just wanted to believe it more.  I don't get much of a
>warm fuzzy from the numbers behind the decimal point though.
>Shouldn't *all* of the values we deal with here be natural
>numbers?  Or, going the other way, if there are indeed 77

No, they shouldn't, because of ZBR technology, where there are more sectors
on some tracks than on others. In non-ZBR disks, it will be a whole number.

...except, depending on the disk, the way sectors are spared out may still
fuzz that number a bit.

>blocks (sectors) per track, 2051 tracks per surface, and 13
>surfaces per disk, shouldn't there be 77 * 2051 * 13 = 2053051
>sectors per disk?  I detect some bogosity to the tune of
>2054864 - 2053051 = 1813 sectors.  Why isn't *that* the number
>returned by these SCSI utilities as the number of sectors...?!

Two reasons. The ZBR stuff, which isn't really covered by the model that
we (i.e., Unix's disktab entries) use, makes the calculation wrong but "close
enough", and as good as you can make it. Sparing can also mess it up a little,
especially since some utilities take that into account and some don't.

>> BTW, using an rg of 0 for my Elite-1 didn't seem to help at all. This still
>> puzzles me- you'd think that the track cache would obsolesce that value and
>> make anything >0 a big lose. But that seems not to be the case.

>Yeah, puzzling indeed....  Have you noticed *any* differences
>(positive or negative) with any different values of rg?  Or do
>all values of rg give the same performance?  Which ones have
>you tried and what were the results if there were differences?

There seemed to be a small negative effect when I tuned it by hand with tunefs.
Didn't really try to get numbers on rg. It didn't seem worth the time,
especially since I had 200 users screaming for access...

>I am usually pretty good at figuring out net acronyms the first
>time I see them, but I am not sure I can get WAG.  Wondering
>And Guessing, perhaps?  There, that last sentence is a WAG!

"Wild-Ass Guess" :-)

>And, no, Alexis, don't worry, I do in fact see your efforts only as
>constructive.  I don't take anything badly I read on the net anyway.

>Thanks for your response.  It clears up much of what I was not
>feeling comfortable with....  Anyone for the last few scraps...?

Hope that pretty much covers it.

--
Alexis Rosen   Owner/Sysadmin,
PANIX Public Access Unix & Internet, NYC.
[e-mail]
{uupsi,cmcl2}!panix!alexis