Subject: Re: NCR Driver Problems
To: Don Lewis <email@example.com>
From: Dave Rand <firstname.lastname@example.org>
Date: 02/02/1996 22:42:32
[In the message entitled "Re: NCR Driver Problems" on Feb 2, 21:56, Don Lewis writes:]
> On Feb 2, 8:25pm, Dave Rand wrote:
> } Subject: Re: NCR Driver Problems
> } random direction seeks - plot the results. Depending on the drive,
> } you will see 3 or more different 'humps' in the seek time, when plotted
> } against number of tracks. Usually, seeks are broken into 'near',
> } 'medium' and 'far', with special cases for boundarys.
> I've heard the latter statement. The existance of humps indicates to
> me that the drive's "average" seek time could be reduced by flattening
> out the humps. The drive should mechanically capable of this, it's
> just the control algorithms that are deficient. Are the humps in the
> middle of the control regions or where they are spliced together? I
> would expect the latter.
There is insufficient processing power in the drive to deal with
hyper-whizzy algorithms. It is inefficient (read - *you* wouldn't
pay for it) to put enough processing power there. It is a compromise.
The problem is the acceleration and braking curves of the actuator.
It takes time to start and stop the head movement. It also takes
energy. This is another compromise.
There is no free lunch. One thing I have found is that the dumber
drives can be faster than the smart drives, when used in a typical
UNIX environment. IDE drives, for example, can often process more
I/O per second than similar (and more expensive) SCSI drives. Some
of this has to do with the command overhead of the drive processing
the SCSI request with a low-end micro.
Filesystem design on modern drives is non-trivial - but if you must
trivialize it, do a few, large I/O's rather than a lot of small I/O's.
> Yup, which brings us to block allocation policy. When extending a
> file, you always want to favor increasing block numbers. You don't
> want to allocate a block just because it's in the same "cylinder",
> since it may not be on the same cylinder on the physical drive.
> And then there is the rotational position stuff ...
Good advice. I wish there was just one type of file, and one
type of user, and one type of application - it would make this
problem a lot easier :-)