[lkml]   [1999]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [OFFTOPIC] Re: disk head scheduling
> On Sun, 21 Mar 1999 wrote:
> Expensive disk drives now do full track buffering. This costs
> money because RAM costs money. To buffer one full track on a
> Disc drive requires CAPACITY / (HEADS * CYLINDERS) which can
> be upwards of 100 megabytes of high-speed SRAM. Sector buffering
> is always necessary. It is part of the de-serializer and is
> required because the Disc internals are never synchronous with
> the outside world.
> Full track buffering suffers from the possibility that the next
> read or write will be on a different head. If the buffer was
> dirtied by a write, it is flushed to the physical media before
> any other operation can take place. To save time, the whole
> track is written. This saves time because you can start the
> write anywhere. However, it still takes 1 revolution of the
> platter.
> Because of this, rotational latency now means nothing either.
> This is another buzzword gone obsolete.
> Full track buffering and other expensive disk optimization techniques
> are usually done in SCSI Disks. However, some enhanced IDE drives
> now provide these features, but not the "Saturday night specials".
I've been reading this thread with some amusement. I don't know where the
idea that full track buffering is only on expensive drives. Almost all drives do
it now. You're right in that rotational latency doesn't mean what it did
in the past. Once the drive had decoded the command it starts filling the
buffer as soon as any of the sectors pass under the head. It may be the
case that the first sector is the last sector to be read (or written). I
don't know where you got the 100MB number from but that would imply a
*very* dense drive. The best I could find was a Seagate Elite at 47GB
(not a terribly fast drive) that has ~10000 cylinders (yes 10^4), 28 heads
and 328 sectors/track. Given that sectors are 512 bytes that's ~150KB.
Inexpensive IDE drives (not this one) have atleast 128K of buffering, many
more expensive SCSI have 1MB or more.

The big falicy with all of the disc optimization that I've seen discussed
is that once you get into volume managment or RAID, none of this matters
because you're now talking about multiple drives. So putting knowledge
into the file system about drive geometry is lunacy because it no longer
makes any sense. Many drives are sophisticated enough to perform their
own queuing internally for multiple commands. Oh, and let's not get into
where the servo information is stored (single platter or "wedge" servo) as
this can affect all sorts of things like how close two sectors on the
track may actually be.

I agree with Linus on this, treat the drive as a linear set of sectors.
About the only assumption you can make (not exactly but good enough) is
that sectors that are far apart (in numbering) are likely to be far apart
in the time to get from one to the other.

TTFN - Guy

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:50    [W:0.137 / U:0.900 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site