DA(4) BSD Kernel Interfaces Manual DA(4)NAMEda — SCSI Direct Access device driver
SYNOPSIS
device da
device da1 at scbus0 target 4 unit 0
DESCRIPTION
The da driver provides support for all SCSI devices of the direct access
class that are attached to the system through a supported SCSI Host
Adapter. The direct access class includes disk, magneto-optical, and
solid-state devices.
A SCSI Host adapter must also be separately configured into the system
before a SCSI direct access device can be configured.
PARTITIONING
The da driver allows the disk to have two levels of partitioning. One
layer, called the “slice layer”, is used to separate the DragonFly areas
of the disk from areas used by other operating systems. The second layer
is the native 4.4BSD partitioning scheme, disklabel(5), which is used to
subdivide the DragonFly slices into areas for individual filesystems and
swap spaces. For more information, see fdisk(8) and disklabel(8),
respectively.
If an uninitialized disk is opened, the slice table will be initialized
with a fictitious DragonFly slice spanning the entire disk. Similarly,
if an uninitialized (or non-DragonFly) slice is opened, its disklabel
will be initialized with parameters returned by the drive and a single
‘c’ partition encompassing the entire slice.
CACHE EFFECTS
Many direct access devices are equipped with read and/or write caches.
Parameters affecting the device's cache are stored in mode page 8, the
caching control page. Mode pages can be examined and modified via the
camcontrol(8) utility.
The read cache is used to store data from device-initiated read ahead
operations as well as frequently used data. The read cache is transpar‐
ent to the user and can be enabled without any adverse effect. Most
devices with a read cache come from the factory with it enabled. The
read cache can be disabled by setting the RCD (Read Cache Disable) bit in
the caching control mode page.
The write cache can greatly decrease the latency of write operations and
allows the device to reorganize writes to increase efficiency and perfor‐
mance. This performance gain comes at a price. Should the device lose
power while its cache contains uncommitted write operations, these writes
will be lost. The effect of a loss of write transactions on a file sys‐
tem is non-deterministic and can cause corruption. Most devices age
write transactions to limit vulnerability to a few transactions recently
reported as complete, but it is none-the-less recommended that systems
with write cache enabled devices reside on an Uninterruptible Power Sup‐
ply (UPS). The da device driver ensures that the cache and media are
synchronized upon final close of the device or an unexpected shutdown
(panic) event. This ensures that it is safe to disconnect power once the
operating system has reported that it has halted. The write cache can be
enabled by setting the WCE (Write Cache Enable) bit in the caching con‐
trol mode page.
TAGGED QUEUING
The da device driver will take full advantage of the SCSI feature known
as tagged queueing. Tagged queueing allows the device to process multi‐
ple transactions concurrently, often re-ordering them to reduce the num‐
ber and length of seeks. To ensure that transactions to distant portions
of the media, which may be deferred indefinitely by servicing requests
nearer the current head position, are completed in a timely fashion, an
ordered tagged transaction is sent every 15 seconds during continuous
device operation.
BAD BLOCK RECOVERY
Direct Access devices have the capability of mapping out portions of
defective media. Media recovery parameters are located in mode page 1,
the Read-Write Error Recovery mode page. The most important media remap‐
ping features are 'Auto Write Reallocation' and 'Auto Read Reallocation'
which can be enabled via the AWRE and ARRE bits, respectively, of the
Read-Write Error Recovery page. Many devices do not ship from the fac‐
tory with these feature enabled. Mode pages can be examined and modified
via the camcontrol(8) utility.
KERNEL CONFIGURATION
It is only necessary to explicitly configure one da device; data struc‐
tures are dynamically allocated as disks are found on the SCSI bus.
IOCTLS
The following ioctl(2) calls apply to SCSI disks as well as to other
disks. They are defined in the header file <sys/disklabel.h>.
DIOCSBAD Usually used to set up a bad-block mapping system on the
disk. SCSI drives incorporate their own bad-block mapping so
this command is not implemented.
DIOCGDINFO Read, from the kernel, the in-core copy of the disklabel for
the drive. This may be a fictitious disklabel if the drive
has never been initialized, in which case it will contain
information read from the SCSI inquiry commands.
DIOCSDINFO Give the driver a new disklabel to use. The driver will not
write the new disklabel to the disk.
DIOCWLABEL Enable or disable the driver's software write protect of the
disklabel on the disk.
DIOCWDINFO Give the driver a new disklabel to use. The driver will
write the new disklabel to the disk.
NOTES
If a device becomes invalidated (media is removed, device becomes unre‐
sponsive) the disklabel and information held within the kernel about the
device will be invalidated. To avoid corruption of a newly inserted
piece of media or a replacement device, all accesses to the device will
be discarded until the last file descriptor referencing the old device is
closed. During this period, all new open attempts will be rejected.
FILES
/dev/rdau raw mode SCSI disk unit u, accessed as an unpartitioned
device
/dev/dausn block mode SCSI disk unit u, slice n, accessed as an
unpartitioned device
/dev/rdausn raw mode SCSI disk unit u, slice n, accessed as an unpar‐
titioned device
/dev/daup block mode SCSI disk unit u, first DragonFly slice, parti‐
tion p
/dev/rdaup raw mode SCSI disk unit u, first DragonFly slice, parti‐
tion p
/dev/dausnp block mode SCSI disk unit u, nth slice, partition p
/dev/rdausnp raw mode SCSI disk unit u, nth slice, partition p
DIAGNOSTICS
None.
SEE ALSOad(4), disklabel(5), disklabel(8), fdisk(8)HISTORY
The da driver was written for the CAM SCSI subsystem by Justin T. Gibbs.
Many ideas were gleaned from the sd device driver written and ported from
Mach 2.5 by Julian Elischer. Support for slices was written by Bruce
Evans.
BSD October 15, 1998 BSD
