lkml.org 
[lkml]   [1999]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: disk head scheduling

On 20 Mar 1999, Linus Torvalds wrote:

> In article <19990319181823.A543@anjala.mit.edu>,
> Arvind Sankar <arvinds@mit.edu> wrote:
> >
> >IBM claims that my hard disk (Model IBM DHEA-38451) has 4 platters and 8 heads.
> >I assume these are physical, since there are either 15 or 16 logical heads in
> >CHS mode (settable via jumpers).
>
> Do they claim how many sectors?
>
> I bet they don't. A lot of the better disks split up the disk in
> "regions", and have a variable number of sectors: more sectors on the
> outer edge where there is more room, etc.
>
> Density is important to modern disks, and as long as disks rotate you
> will have a property where the outer tracks have more space.

Yes, that's the method used to increase capacity. But this increases also
complexity and probably may affect performances due to more complexity in
the firmware. Btw, the Chetaah2 reports a fixed geometry of 6962 tracks of
214 sectors each, and this perhaps explains the reasons it performs so
well.

> Quite frankly, anybody who even _thinks_ he knows how the disk is
> organized is living in the past. Give up on it, and just consider it a
> linear array of sectors. Anything else just amounts to repeatedly
> hitting yourself on the head with a virtual icepick, and is just about
> as useful.

Indeed.

> Just say no to unnecessary complexity that just doesn't buy you
> anything. Linux uses a one-way scheduler for many good reasons, not the
> least of which are that it is fair and that it is simple.

The current request queue in Linux is probably a excellent helper for IDE
disks and SCSI disks when using a small number of tagged commands and a
small number of disks at the same time, but for high-end SCSI we want to
use numerous disks at the same time and to queue them a large number of
tagged commands. A request queue per disk would probably perform better.
On the other hand recent drives seem to do a great job for seeks
optimization when they are supplied with enough commands, so trying to be
too much clever for optimizing seeks from the kernel would probably not
help in this case.

Obviously, we want to take care, regardless the disk capabilities and
interface type, to coalesce IO requests into larger requests when it is
possible.

Probably a linux-2.3/4 issue. The current Linux io-request scheduler has
the advantage to be simple and does not seem to be that broken for common
situations.

> The same goes for filesystems: trying to optimize the filesystem for
> some random number of sectors per track is just stupid these days.

Indeed.

> Linus

PS: I didn't see any ac-patch addressing this issue for 2.2.
Did I miss something. ;-)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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