Optimization for caching controllers

[Larry Blair]

In a response to "Are fileservers a waste of money", I talked about using
a caching disk controller, and said:

> Be sure to do a tunefs -a 16 to get the full caching advantage.

I received a mail message from Glenn P. Davis <ames!unidata.UCAR.EDU!davis>

> Please explain this.

After sending him this reply, I thought that it might be of interest to
other sun-spots readers.

Using a non-caching disk controller and BSD's traditional one sector at a
time transfers, it is impossible to read successive physical blocks from a
disk without having to wait for the disk to rotate completely around for
each sector.  BSD automatically tries to compensate this by utilizing the
sectors in a hopscotch arrangement that separates the sectors used to
write a file by a distance that is hopefully wide enough so that when the
file is read back, each successive read will be started before the next
sector needed has passed the head.

With caching controllers, reading a particular sector will cause that
sector, along with the following sectors on the track to all be read into
the cache in one pass.  [Actually, it a little bit more complex than that,
but the concept is sufficient for this discussion.]  If the sectors used
to create the file were written using successive physical sectors, the
likelyhood of cache hits on subsequent reads are pretty high.  Tunefs(8)
allows your to adjust how the sectors on the disk are utilized.

Now for the voodoo.  Many people using the Interphase or Ciprico simply do
a "tunefs -d 0", which eliminates all compensation for rotational delay.
After thinking about that, I decided to do a little testing.  SunOS reads
and writes are based on an 8K logical block size, when comes to 16
sectors.  Of course, not all accesses are going to be for the full 8K, but
none are going to be larger.  I suspected that inserting a rotational
delay between each group of 16 sectors might be an improvement.

I spent most of a day with an Interphase 4200 and a CDC FSD-340 playing.
I found that I got better results for both reading and writing with "-a
16" than I did for "-d 0".  I don't have the exact result around anymore,
but I do remember that "-d 0" actually resulted in a slower write time
than the default delay.  Using "-a 16" resulted in a reduction from 25
seconds (for the default settings) to 9 seconds for my read test.

These tests were hardly definitive.  I suspect that along with "-a 16",
the rotational delay gap should be adjusted.  I didn't have enough time to
test it.


Larry Blair   ames!vsi1!lmb   lmb at vicom.com