SD(4) BSD Programmer's Manual SD(4)NAME
sd, sr - machine-independent SCSI disk driver
SYNOPSIS
sr0 at tg? unit 0 flags 0
sr* at tg? unit ? flags 0
sd0 at tg? unit 0 flags 0
sd* at tg? unit ? flags 0
DESCRIPTION
The sd driver for disks on the Small Computer System Interface (ANSI
X3.131-1992) bus is a machine-independent generic device which employs
machine-dependent drivers for individual host bus adapters (see hba(4))
to read and write data blocks. The sd driver takes care of queuing re-
quests and sorting them by cylinder address on each logical unit; gener-
ating the correct read and write SCSI Command Descriptor Blocks, along
with inquiry, test unit ready and other common operations; reading and
writing disk labels; and classifying SCSI errors and gathering extended
error information. The driver also supports an interface for raw SCSI
commands; see scsicmd(8).
The clone entries sd* and sr* should be listed last; these will automati-
cally match any otherwise unmatched SCSI disks. Additional instances of
sd or sr devices can be ``wired'' to particular targets as described in
tg(4).
The sr device is an alias for sd in most respects. WORM's, jukeboxes, CD-
ROM's, magneto optical, and regular magnetic disks are considered by the
sr and sd drivers. The sr driver will attach itself to removable media
and the sd device will attach to any devices remaining. It is important
to list sr devices before sd devices in the configuration file.
If the device flags for an sr device are 0x01 it will not match any de-
vices (this causes all remaining unattached devices to attach to the sd
driver).
The split between the two aliases is used to segregate removable storage
(typically CD-ROMS's) from magnetic storage for administrative conve-
nience.
If pre-2.1 behavior is desired add "-dev sr0 flags=0x1" to the
/etc/boot.default file or type it at the Boot: command line.
TAG QUEUEING
Beginning with BSD/OS 3.0 tag queueing is supported by the SCSI framework
and the sd driver. It is now possible to write and read files with no in-
terleave at full disk speed. There are however a couple of caveats:
1 Many drives which support tag queueing have bugs in the firmware.
In some cases these bugs cause the drives to lock up, in other cases
data will be silently corrupted. To make matters worse it is almost
impossible to find out if a particular version of firmware from a
particular vendor is known to work. There is no easy solution to
this problem. Currently (Sept 1996) it appears that major vendors
ship drives with firmware that will successfully run with tag queue-
ing. However, drives from these same vendors with firmware which is
not the latest may fail.
Most, but not all of the HBA drivers support tag queueing. Those HBA
drivers which support tag queueing do not enable it by default be-
cause of the problems with many drives. See the man page for the HBA
driver to determine how to enable tag queueing for the particular
HBA driver.
2 In order to gain significant advantage from tag queueing it is nec-
essary to manually change the rotational delay between contiguous
blocks to zero. Typically tunefs(8)-d 0 would be used to make this
change. Take note of the BUGS section of the tunefs(8) man page.
RAID SUPPORT
Under normal conditions the sd driver will only concurrently start 1, or
in the case of tag queueing 3, io operations on a given unit. Starting
more operations would reduce the efficiency of the elevator sort done by
the sd driver. Units which are raid controllers typically have multiple
physical drives. In order to get maximum throughput these raid controller
need to have io operations they can run on all, or at least many, of the
physical drives they are controlling. There is now a parameter config-
urable with boot(8) to adjust the number of concurrent operations. The
-parm command is used to set the ``concurrency'' parameter. The value
that ``concurrency'' is set to can either be a numeric or the keyword
``raid''. Setting ``concurrency'' to ``raid'' sets the concurrency to an
arbitrarily large number, which will in turn cause as many operations to
be run concurrently as possible, limited by the HBA's capabilities.
Since the HBA will limit the number of operations to 1 if tag queueing is
not enabled, tag queueing must be enabled for this parameter to have any
effect. The following are examples of lines which would be added to
boot.default:
-parm sd* concurrency=1 #the default without tags
-parm sd* concurrency=2 #the default tags
-parm sd1 concurrency=raid #run as many operations as possible
concurrently on sd1
-parm sd2 concurrency=5 #run 5 operations concurrently on sd2
FILES
/dev/sd*[a-h] block SCSI devices
/dev/rsd*[a-h] raw SCSI devices
/dev/sr*[a-h] block SCSI removable devices
/dev/rsr*[a-h] raw SCSI removable devices
SEE ALSOhba(4), tg(4), sg(4), st(4), scsicmd(8)HISTORY
This driver was written by Chris Torek for SPARC BSD, and was contributed
by his employer, the Lawrence Berkeley Laboratories.
The current driver has been modified to fit into the current SCSI frame-
work which first shipped in BSD/OS 3.0.
BUGS
Errors returned by the driver consist of a sense key and possible addi-
tional sense information. The sense key is printed in English but the
myriad ASC and ASCQ values must be decoded using the -a option of
scsicmd.
On some machines, standalone boot blocks and 14-sector bootstraps are
necessarily dependent on the host adapter. There are no sdboot or bootsd
files; these are instead named after individual host adapters.
BSDI BSD/OS September 15, 1995 2