.\" Copyright (c) 1990 The Regents of the University of California.
.\" This code is derived from software contributed to Berkeley by
.\" the Systems Programming Group of the University of Utah Computer
.\" %sccs.include.redist.man%
.\" @(#)rd.4 5.1 (Berkeley) %G%
rd \- CS/80 disk interface
.B "master hpib? at scode?"
.B "disk rd? at hpib? slave?"
This is a generic CS/80 disk driver.
Only a small number of possible CS/80 drives are supported,
but others can easily be added by adding tables to the driver.
Files with minor device numbers 0 through 7 refer to various portions
minor devices 8 through 15 refer to drive 1, etc.
The standard device names begin with ``rd'' followed by
the drive number and then a letter a-h for partitions 0-7 respectively.
The character ? stands here for a drive number in the range 0-7.
The block files access the disk via the system's normal
buffering mechanism and may be read and written without regard to
physical disk records. There is also a `raw' interface
which provides for direct transmission between the disk
and the user's read or write buffer.
A single read or write call results in exactly one I/O operation
and therefore raw I/O is considerably more efficient when
many words are transmitted. The names of the raw files
conventionally begin with an extra `r.'
In raw I/O counts should be a multiple of 512 bytes (a disk sector).
calls should specify a multiple of 512 bytes.
The driver interrogates the controller
to determine the type of drive attached.
The driver recognizes the following drives:
7912, 7914, 7933, 7936, 7937, 7945, 7957A/B, 7958A/B,
7959B, 7962, 7963, 9122, 9134, 7912, 7936, and 9122,
not all of which have been tested.
The origin and size of the pseudo-disks on each drive are
.ta .5i +\w'000000 'u +\w'000000 'u +\w'000000 'u
rd?f 179648 78400 802-1151
rd?g 56448 201600 252-1151
rd?h 81088 176960 362-1151
rd?e 64764 100800 257-656
rd?f 165564 89712 657-1012
rd?g 48636 206640 193-1012
rd?h 64764 190512 257-1012
rd?f 113344 46200 736-1035
rd?g 40810 118734 265-1035
rd?h 58520 101024 380-1035
rd?e 99866 165646 167-443
rd?f 265512 165646 444-720
rd?g 83720 706238 140-1320
rd?h 431158 358800 721-1320
rd?e 100737 120540 117-256
rd?f 220416 120540 256-395
rd?h 341817 259161 397-697
rd?e 100737 246246 63-216
rd?f 346983 246246 217-370
rd?g 84747 1031355 53-697
rd?h 593229 522873 371-697
rd?f 115668 44226 918-1268
rd?g 48888 111006 388-1268
rd?h 65268 94626 518-1268
rd?e 65772 121716 174-495
rd?f 187488 109620 496-785
rd?g 49518 247590 131-785
rd?h 65772 231336 174-785
rd?e 82404 303912 218-1021
rd?f 386316 207900 1022-1571
rd?g 65772 528444 174-1571
rd?h 82404 511812 218-1571
It is unwise for all of these files to be present in one installation,
since there is overlap in addresses and protection becomes
The eight partitions as given support four basic, non-overlapping layouts,
though not all partitions exist on all drive types.
In the first layout there are three partitions and a ``bootblock'' area.
The bootblock area is at the beginning of the disk and holds
the standalone disk boot program.
The rd?a partition is for the root file system,
rd?b is a paging/swapping area, and
rd?g is for everything else.
The second layout is the same idea,
but has a larger paging/swapping partition (rd?d) and
a smaller ``everything else'' partition (rd?h).
This layout is better for environments which run many large processes.
The third layout is a variation of the second,
but breaks the rd?h partition into two partitions, rd?e and rd?f.
The final layout is intended for a large, single file system second disk.
It is also used when writing out the boot program since it is the only
partition mapping the bootblock area.
/dev/rd[0-7][a-h] block files
/dev/rrd[0-7][a-h] raw files
\fBrd%d err: v%d u%d, R0x%x F0x%x A0x%x I0x%x, block %d\fR
An unrecoverable data error occurred during transfer of the
specified block on the specified disk.
The current disk partitioning is totally bogus.
CS/80 drives have 256 byte sectors which are mapped to 512 byte
``sectors'' by the driver.
Since some CS/80 drives have an odd number of sectors per cylinder,
the disk geometry used is not always accurate.
The partition tables for the file systems should be read off of each pack,
as they are never quite what any single installation would prefer,
and this would make packs more portable.
truncate file offsets to 512-byte block boundaries,
scribbles on the tail of incomplete blocks.
in programs that are likely to access raw devices,
should always deal in 512-byte multiples.
A program to analyze the logged error information (even in its
present reduced form) is needed.
projects / unix-history / blob