[TUHS] Boston Children's Museum RK05 Driver: Questions

[TUHS] Boston Children's Museum RK05 Driver: Questions

[Warren Toomey via TUHS]

Hi all, for some reason I thought about the RK05 driver written by
Bill Mayhew and Brent Byer at the Boston Children's Museum. Based
on the minor device number, it remaps blocks 1 to 2435 as blocks
2436 to 4871, and remaps blocks 2436 to 4871 down to blocks 1 to 2435.

According to the notes in the driver (see dmr/rk.c in
https://www.tuhs.org/Archive/Distributions/UNSW/1/record0.tar.gz):

  The effect of this mapping is to centralize disk head motion about the
  center of the disk. The optimization is ideal for those RK's which
  serve as both root device and swap device. It is less than ideal,
  although probably still an improvement over traditional form, for RK's
  used exclusively as mounted file systems.

Question: how much of a win was this, and why was the idea of moving
(some/all) of the i-nodes to the centre of the disk not used until
we got the fast filesystem?

Cheers, Warren

[TUHS] Re: Boston Children's Museum RK05 Driver: Questions

[Paul Winalski via TUHS]

On Sat, Jan 31, 2026 at 9:01 PM Warren Toomey via TUHS <tuhs@tuhs.org>
wrote:

>
> Question: how much of a win was this, and why was the idea of moving
> (some/all) of the i-nodes to the centre of the disk not used until
> we got the fast filesystem?
>
> It was not uncommon to have unconventional data placement schemes on disk
files to minimize head movement.  IBM's compilers used something called
split cylinder allocation for their compilers' three scratch files.
Instead of having a contiguous set of cylinders for each file, each
cylinder was split between the three scratch files (for example, file #1
using heads 1-3, file #2 heads 5-7, etc.).  This allowed the compiler to
use the three files simultaneously with little or no head movement.

I imagine that by the time the fast filesystem came along memory was cheap
and plentiful enough to allow sufficient caching (both in the disk
controller and by the driver) to mitigate most head motion delays for
frequently accessed data structures such as inodes.

-Paul W.