On Feb 2,  8:25pm, Dave Rand wrote:
} Subject: Re: NCR Driver Problems
} [In the message entitled "Re: NCR Driver Problems" on Feb  1, 17:00, Don Lewis writes:]
} > On Jan 31,  3:34pm, proprietor - Foo Bar And Grill wrote:
} > } 
} > } So, in other words, disksort() is now obsolete and should be replaced.
} > 
} > If the drive you're talking to only has a single actuator, then you still
} > want to preprocess the queue with disksort() so that all the commands
} > sent to the drive are for sectors that are close together.  The drive
} > can then do the final optimization based on it's real time head and
} > rotational position status.
} 
} disksort(), on modern drives, is pretty obsolete.

Trying to optimize the storage layout based on pretend disk geometry
is pretty dumb, but disksort at least orders the requests as they
are sent to the drive instead of letting them be totally random as
they would be if we just emptied the queue in FIFO order.  That said,
disksort is way too complicated.  It should really just be sorting on
logical block addresses.

} What is important is to pre-read data, preserve locality, and read/write
} as much data in one command as is reasonable.

Yup.  But this a function of the filesystem layer, which has the most
information about what data is likely to soon be wanted, etc.

} One reason for this is that 'geometry' of drives is meaningless.
} What you think is a perfectly reasonable read request, not spanning
} tracks, man end up causing a seek anyway.  With variable bit rates,
} and sector packing, the number of sectors per track is no longer anything
} that can be counted on.

Yup.  Even an operation which causes the drive to switch heads may
cause a seek.

} The second problem is seeks themselves.  Seek time has not been linear
} with number of tracks crossed for about 15 years.  There are several
} algorithms employed, depending on 'how far', 'which direction', 'what
} temperature', and other more bizzare factors.  A 5 track seek may
} take as long (or longer) than a 50 track seek.

Cute.

} Certain seek patterns,
} like seek to track zero, may have even more bizzare behavior (faster
} or slower than equivilent-direction seek).  To examine this, turn
} your drive's cache off (and any second-level caches in the controller),
} and do several hundred seeks, from 1 to 'many' tracks. Now, do some
} 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.

The details don't really matter to us if we sort requests by address.
Of course, if we had a good model for the drive, we could attempt to
optimize performance by solving the travelling salesman problem ;-)

} The third problem is sector aliasing, or sector re-mapping.  Hopefully
} a problem that can be ignored, it may cause an otherwise reasonable
} drive to perform poorly under certain conditions.  A string of
} bad sectors on a test directory, forcing bizzare, unexpected seeks to
} the top of the drive to read the 'good' sectors...  impossible to
} predict.

In general I would think this could be ignored.  This situation should
occur infrequently enough that it shouldn't greatly affect overall
performance.  I would think that it would only be a problem if there
are strict real-time performance requirements, in which case the best
solution would be to mark these sectors as bad and let the filesystem
allocate around them.  Of course, in order to do this the OS needs to
get a list of the re-mapped sectors from the drive.

} The last problem is the drive 'helping' with its first level cache.
} Under DOS, these caches do good things.  Under UNIX - well, if it
} doesn't really hurt the performance *too* bad, the drive software
} engineer did a spectacular job.

I would expect a slight performance gain here.  If there are closely
spaced read requests and the host is slow and/or the SCSI bus is
busy, the second read could be satisfied from the drive's cache if
it does read-ahead and the second request arrived after the desired
sector passed.

} These factors change on every new drive - sometimes even new models of
} the same drive.  The are somewhere between hard, and impossible to
} model (unless you have inside knowledge of the drive at hand).
} So the best course, with modern drives, is to read and write as
} much data as is possible in one operation, sequentially, and
} hope for the best.

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 ...

			---  Truck