[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Disk geommetry, was Re: Kernel Upgrade: Why?



Jonathan Guthrie <jguthrie@brokersys.com> writes:

> On Thu, 22 Apr 1999, Ookhoi wrote:
> 
> > Well, there was a discussion here about a benchmark Linux vs NT, and
> > some people here said that the preformance of Linux could have been
> > affected by the fact that Linux was near the center, and NT on the outer
> > side. 
> 
> Probably not the reason. 
> 
> > And the data on the outer side passes the heads much faster than the
> > data on the inner side. But then, there is much more data on the outer
> > side, and a piece of data on the outer side will go round in the same 
> > amount of time as a piece of data on the inner side..
> 
> I am not aware of any disks that use a higher density recording format for
> the outer tracks than they do for the inner tracks.  As far as I am aware
> (and I really haven't paid much attention to such things since ST-277's
> were state of the art) the bit density of the outer tracks is LOWER than
> the bit density of the inner tracks.  That's because the outer tracks are
> physically larger, but they hold the same number of bits.

The ST-277 did work the way you described, but no modern drives do.
The outer tracks do contain more sectors than the inner tracks.  Since
more sectors pass by on outer tracks in a fixed time, a single sector
is read faster in the outer tracks than the inner tracks.

> Not that it matters.  The whole disk spins as a single unit so even if
> there were more bits on the outer tracks, you'll still wait the same
> amount of time (on average) for the sector you want to come around.

I agree that the seek time and latency time will be the same, but you
will read more data in a single rotation.  Reading small files will
probably be dominated by seek time, so there should be little
difference between inner and outer tracks.  Large files are largely
consecutive sectors, so they should read faster on the outer tracks
than the inner tracks.

-- 
Carl Johnson		carlj@peak.org


Reply to: