1996-10-18 20:22:31 +00:00
|
|
|
.\" Copyright (c) 1996
|
2000-10-26 15:30:44 +00:00
|
|
|
.\" Julian Elischer <julian@FreeBSD.org>. All rights reserved.
|
1996-10-18 20:22:31 +00:00
|
|
|
.\"
|
|
|
|
.\" Redistribution and use in source and binary forms, with or without
|
|
|
|
.\" modification, are permitted provided that the following conditions
|
|
|
|
.\" are met:
|
|
|
|
.\" 1. Redistributions of source code must retain the above copyright
|
|
|
|
.\" notice, this list of conditions and the following disclaimer.
|
|
|
|
.\"
|
|
|
|
.\" 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
.\" notice, this list of conditions and the following disclaimer in the
|
|
|
|
.\" documentation and/or other materials provided with the distribution.
|
|
|
|
.\"
|
|
|
|
.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
|
|
|
|
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
|
|
|
|
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
|
|
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
|
|
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
|
|
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
|
|
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
|
|
.\" SUCH DAMAGE.
|
|
|
|
.\"
|
1999-08-28 00:22:10 +00:00
|
|
|
.\" $FreeBSD$
|
1996-12-26 16:16:37 +00:00
|
|
|
.\"
|
2012-02-09 04:37:30 +00:00
|
|
|
.Dd February 8, 2012
|
1998-10-16 03:28:12 +00:00
|
|
|
.Dt DA 4
|
2001-07-10 15:31:11 +00:00
|
|
|
.Os
|
1995-01-25 09:18:56 +00:00
|
|
|
.Sh NAME
|
1998-10-16 03:28:12 +00:00
|
|
|
.Nm da
|
2001-04-18 15:54:10 +00:00
|
|
|
.Nd SCSI Direct Access device driver
|
1995-01-25 09:18:56 +00:00
|
|
|
.Sh SYNOPSIS
|
2000-01-23 15:04:20 +00:00
|
|
|
.Cd device da
|
1995-01-25 09:18:56 +00:00
|
|
|
.Sh DESCRIPTION
|
|
|
|
The
|
2000-11-20 18:41:33 +00:00
|
|
|
.Nm
|
1998-10-16 03:28:12 +00:00
|
|
|
driver provides support for all
|
1996-01-18 21:36:18 +00:00
|
|
|
.Tn SCSI
|
1998-10-16 03:28:12 +00:00
|
|
|
devices of the direct access class that are attached to the system
|
|
|
|
through a supported
|
1996-01-18 21:36:18 +00:00
|
|
|
.Tn SCSI
|
1998-10-16 03:28:12 +00:00
|
|
|
Host Adapter.
|
|
|
|
The direct access class includes disk, magneto-optical,
|
|
|
|
and solid-state devices.
|
|
|
|
.Pp
|
1996-01-18 21:36:18 +00:00
|
|
|
A
|
|
|
|
.Tn SCSI
|
1998-10-16 03:28:12 +00:00
|
|
|
Host
|
1996-01-18 21:36:18 +00:00
|
|
|
adapter must also be separately configured into the system
|
|
|
|
before a
|
|
|
|
.Tn SCSI
|
1998-10-16 03:28:12 +00:00
|
|
|
direct access device can be configured.
|
|
|
|
.Sh CACHE EFFECTS
|
1999-04-30 06:37:16 +00:00
|
|
|
Many direct access devices are equipped with read and/or write caches.
|
1998-10-16 03:28:12 +00:00
|
|
|
Parameters affecting the device's cache are stored in mode page 8,
|
2003-06-28 23:53:39 +00:00
|
|
|
the caching control page.
|
|
|
|
Mode pages can be examined and modified via the
|
1998-10-16 03:28:12 +00:00
|
|
|
.Xr camcontrol 8
|
|
|
|
utility.
|
2000-11-14 11:20:58 +00:00
|
|
|
.Pp
|
1999-04-30 06:37:16 +00:00
|
|
|
The read cache is used to store data from device-initiated read ahead
|
2003-06-28 23:53:39 +00:00
|
|
|
operations as well as frequently used data.
|
|
|
|
The read cache is transparent
|
2004-07-03 18:29:24 +00:00
|
|
|
to the user and can be enabled without any adverse effect.
|
|
|
|
Most devices
|
2003-06-28 23:53:39 +00:00
|
|
|
with a read cache come from the factory with it enabled.
|
|
|
|
The read cache can be disabled by setting the
|
1998-10-16 03:28:12 +00:00
|
|
|
.Tn RCD
|
|
|
|
(Read Cache Disable) bit in the caching control mode page.
|
2000-11-14 11:20:58 +00:00
|
|
|
.Pp
|
1998-10-16 03:28:12 +00:00
|
|
|
The write cache can greatly decrease the latency of write operations
|
|
|
|
and allows the device to reorganize writes to increase efficiency and
|
2003-06-28 23:53:39 +00:00
|
|
|
performance.
|
|
|
|
This performance gain comes at a price.
|
|
|
|
Should the device
|
1998-10-16 03:28:12 +00:00
|
|
|
lose power while its cache contains uncommitted write operations, these
|
2003-06-28 23:53:39 +00:00
|
|
|
writes will be lost.
|
|
|
|
The effect of a loss of write transactions on
|
|
|
|
a file system is non-deterministic and can cause corruption.
|
|
|
|
Most
|
1998-10-16 03:28:12 +00:00
|
|
|
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
|
2003-06-28 23:53:39 +00:00
|
|
|
Power Supply (UPS).
|
|
|
|
The
|
2000-11-20 18:41:33 +00:00
|
|
|
.Nm
|
1998-10-16 03:28:12 +00:00
|
|
|
device driver ensures that the cache and media are synchronized upon
|
2004-07-02 19:07:33 +00:00
|
|
|
final close of the device or an unexpected shutdown (panic) event.
|
2003-06-28 23:53:39 +00:00
|
|
|
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
|
1998-10-16 03:28:12 +00:00
|
|
|
.Tn WCE
|
|
|
|
(Write Cache Enable) bit in the caching control mode page.
|
|
|
|
.Sh TAGGED QUEUING
|
|
|
|
The
|
2000-11-20 18:41:33 +00:00
|
|
|
.Nm
|
1998-10-16 03:28:12 +00:00
|
|
|
device driver will take full advantage of the SCSI feature known as tagged
|
2003-06-28 23:53:39 +00:00
|
|
|
queueing.
|
|
|
|
Tagged queueing allows the device to process multiple transactions
|
1998-10-16 03:28:12 +00:00
|
|
|
concurrently, often re-ordering them to reduce the number and length of
|
2003-06-28 23:53:39 +00:00
|
|
|
seeks.
|
|
|
|
To ensure that transactions to distant portions of the media,
|
1998-10-16 03:28:12 +00:00
|
|
|
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.
|
|
|
|
.Sh BAD BLOCK RECOVERY
|
|
|
|
Direct Access devices have the capability of mapping out portions of
|
2003-06-28 23:53:39 +00:00
|
|
|
defective media.
|
|
|
|
Media recovery parameters are located in mode page 1,
|
|
|
|
the Read-Write Error Recovery mode page.
|
|
|
|
The most important media
|
1998-10-16 03:28:12 +00:00
|
|
|
remapping features are 'Auto Write Reallocation' and 'Auto Read
|
|
|
|
Reallocation' which can be enabled via the AWRE and ARRE bits,
|
1999-04-30 06:37:16 +00:00
|
|
|
respectively, of the Read-Write Error Recovery page.
|
1998-10-16 03:28:12 +00:00
|
|
|
Many devices do not ship from the factory with these feature enabled.
|
2002-01-21 12:09:13 +00:00
|
|
|
Mode pages can be examined and modified
|
1999-08-09 14:31:04 +00:00
|
|
|
via the
|
1998-10-16 03:28:12 +00:00
|
|
|
.Xr camcontrol 8
|
|
|
|
utility.
|
1995-01-25 09:18:56 +00:00
|
|
|
.Sh KERNEL CONFIGURATION
|
1996-01-18 21:36:18 +00:00
|
|
|
It is only necessary to explicitly configure one
|
2000-11-20 18:41:33 +00:00
|
|
|
.Nm
|
1996-01-18 21:36:18 +00:00
|
|
|
device; data structures are dynamically allocated as disks are found
|
|
|
|
on the
|
|
|
|
.Tn SCSI
|
|
|
|
bus.
|
Move dynamic sysctl(8) variable creation for the cd(4) and da(4) drivers
out of cdregister() and daregister(), which are run from interrupt context.
The sysctl code does blocking mallocs (M_WAITOK), which causes problems
if malloc(9) actually needs to sleep.
The eventual fix for this issue will involve moving the CAM probe process
inside a kernel thread. For now, though, I have fixed the issue by moving
dynamic sysctl variable creation for these two drivers to a task queue
running in a kernel thread.
The existing task queues (taskqueue_swi and taskqueue_swi_giant) run in
software interrupt handlers, which wouldn't fix the problem at hand. So I
have created a new task queue, taskqueue_thread, that runs inside a kernel
thread. (It also runs outside of Giant -- clients must explicitly acquire
and release Giant in their taskqueue functions.)
scsi_cd.c: Remove sysctl variable creation code from cdregister(), and
move it to a new function, cdsysctlinit(). Queue
cdsysctlinit() to the taskqueue_thread taskqueue once we
have fully registered the cd(4) driver instance.
scsi_da.c: Remove sysctl variable creation code from daregister(), and
move it to move it to a new function, dasysctlinit().
Queue dasysctlinit() to the taskqueue_thread taskqueue once
we have fully registered the da(4) instance.
taskqueue.h: Declare the new taskqueue_thread taskqueue, update some
comments.
subr_taskqueue.c:
Create the new kernel thread taskqueue. This taskqueue
runs outside of Giant, so any functions queued to it would
need to explicitly acquire/release Giant if they need it.
cd.4: Update the cd(4) man page to talk about the minimum command
size sysctl/loader tunable. Also note that the changer
variables are available as loader tunables as well.
da.4: Update the da(4) man page to cover the retry_count,
default_timeout and minimum_cmd_size sysctl variables/loader
tunables. Remove references to /dev/r???, they aren't used
any longer.
cd.9: Update the cd(9) man page to describe the CD_Q_10_BYTE_ONLY
quirk.
taskqueue.9: Update the taskqueue(9) man page to describe the new thread
task queue, and the taskqueue_swi_giant queue.
MFC after: 3 days
2003-09-03 04:46:28 +00:00
|
|
|
.Sh SYSCTL VARIABLES
|
|
|
|
The following variables are available as both
|
|
|
|
.Xr sysctl 8
|
|
|
|
variables and
|
|
|
|
.Xr loader 8
|
|
|
|
tunables:
|
|
|
|
.Bl -tag -width 12
|
|
|
|
.It kern.cam.da.retry_count
|
|
|
|
.Pp
|
|
|
|
This variable determines how many times the
|
|
|
|
.Nm
|
|
|
|
driver will retry a READ or WRITE command.
|
|
|
|
This does not affect the number of retries used during probe time or for
|
|
|
|
the
|
|
|
|
.Nm
|
|
|
|
driver dump routine.
|
|
|
|
This value currently defaults to 4.
|
|
|
|
.It kern.cam.da.default_timeout
|
|
|
|
.Pp
|
|
|
|
This variable determines how long the
|
|
|
|
.Nm
|
|
|
|
driver will wait before timing out an outstanding command.
|
|
|
|
The units for this value are seconds, and the default is currently 60
|
|
|
|
seconds.
|
|
|
|
.It kern.cam.da.%d.minimum_cmd_size
|
|
|
|
.Pp
|
|
|
|
This variable determines what the minimum READ/WRITE CDB size is for a
|
|
|
|
given
|
|
|
|
.Nm
|
|
|
|
unit.
|
|
|
|
(The %d above denotes the unit number of the
|
|
|
|
.Nm
|
2004-07-03 18:29:24 +00:00
|
|
|
driver instance, e.g.\& 1, 2, 4, 8, etc.)
|
Move dynamic sysctl(8) variable creation for the cd(4) and da(4) drivers
out of cdregister() and daregister(), which are run from interrupt context.
The sysctl code does blocking mallocs (M_WAITOK), which causes problems
if malloc(9) actually needs to sleep.
The eventual fix for this issue will involve moving the CAM probe process
inside a kernel thread. For now, though, I have fixed the issue by moving
dynamic sysctl variable creation for these two drivers to a task queue
running in a kernel thread.
The existing task queues (taskqueue_swi and taskqueue_swi_giant) run in
software interrupt handlers, which wouldn't fix the problem at hand. So I
have created a new task queue, taskqueue_thread, that runs inside a kernel
thread. (It also runs outside of Giant -- clients must explicitly acquire
and release Giant in their taskqueue functions.)
scsi_cd.c: Remove sysctl variable creation code from cdregister(), and
move it to a new function, cdsysctlinit(). Queue
cdsysctlinit() to the taskqueue_thread taskqueue once we
have fully registered the cd(4) driver instance.
scsi_da.c: Remove sysctl variable creation code from daregister(), and
move it to move it to a new function, dasysctlinit().
Queue dasysctlinit() to the taskqueue_thread taskqueue once
we have fully registered the da(4) instance.
taskqueue.h: Declare the new taskqueue_thread taskqueue, update some
comments.
subr_taskqueue.c:
Create the new kernel thread taskqueue. This taskqueue
runs outside of Giant, so any functions queued to it would
need to explicitly acquire/release Giant if they need it.
cd.4: Update the cd(4) man page to talk about the minimum command
size sysctl/loader tunable. Also note that the changer
variables are available as loader tunables as well.
da.4: Update the da(4) man page to cover the retry_count,
default_timeout and minimum_cmd_size sysctl variables/loader
tunables. Remove references to /dev/r???, they aren't used
any longer.
cd.9: Update the cd(9) man page to describe the CD_Q_10_BYTE_ONLY
quirk.
taskqueue.9: Update the taskqueue(9) man page to describe the new thread
task queue, and the taskqueue_swi_giant queue.
MFC after: 3 days
2003-09-03 04:46:28 +00:00
|
|
|
Valid minimum command size values are 6, 10, 12 and 16 bytes.
|
|
|
|
The default is 6 bytes.
|
|
|
|
.Pp
|
|
|
|
The
|
|
|
|
.Nm
|
|
|
|
driver issues a CAM Path Inquiry CCB at probe time to determine whether the
|
2005-02-13 22:25:33 +00:00
|
|
|
protocol the device in question speaks (e.g.\& ATAPI) typically does not allow
|
Move dynamic sysctl(8) variable creation for the cd(4) and da(4) drivers
out of cdregister() and daregister(), which are run from interrupt context.
The sysctl code does blocking mallocs (M_WAITOK), which causes problems
if malloc(9) actually needs to sleep.
The eventual fix for this issue will involve moving the CAM probe process
inside a kernel thread. For now, though, I have fixed the issue by moving
dynamic sysctl variable creation for these two drivers to a task queue
running in a kernel thread.
The existing task queues (taskqueue_swi and taskqueue_swi_giant) run in
software interrupt handlers, which wouldn't fix the problem at hand. So I
have created a new task queue, taskqueue_thread, that runs inside a kernel
thread. (It also runs outside of Giant -- clients must explicitly acquire
and release Giant in their taskqueue functions.)
scsi_cd.c: Remove sysctl variable creation code from cdregister(), and
move it to a new function, cdsysctlinit(). Queue
cdsysctlinit() to the taskqueue_thread taskqueue once we
have fully registered the cd(4) driver instance.
scsi_da.c: Remove sysctl variable creation code from daregister(), and
move it to move it to a new function, dasysctlinit().
Queue dasysctlinit() to the taskqueue_thread taskqueue once
we have fully registered the da(4) instance.
taskqueue.h: Declare the new taskqueue_thread taskqueue, update some
comments.
subr_taskqueue.c:
Create the new kernel thread taskqueue. This taskqueue
runs outside of Giant, so any functions queued to it would
need to explicitly acquire/release Giant if they need it.
cd.4: Update the cd(4) man page to talk about the minimum command
size sysctl/loader tunable. Also note that the changer
variables are available as loader tunables as well.
da.4: Update the da(4) man page to cover the retry_count,
default_timeout and minimum_cmd_size sysctl variables/loader
tunables. Remove references to /dev/r???, they aren't used
any longer.
cd.9: Update the cd(9) man page to describe the CD_Q_10_BYTE_ONLY
quirk.
taskqueue.9: Update the taskqueue(9) man page to describe the new thread
task queue, and the taskqueue_swi_giant queue.
MFC after: 3 days
2003-09-03 04:46:28 +00:00
|
|
|
6 byte commands.
|
2005-02-13 22:25:33 +00:00
|
|
|
If it does not, the
|
Move dynamic sysctl(8) variable creation for the cd(4) and da(4) drivers
out of cdregister() and daregister(), which are run from interrupt context.
The sysctl code does blocking mallocs (M_WAITOK), which causes problems
if malloc(9) actually needs to sleep.
The eventual fix for this issue will involve moving the CAM probe process
inside a kernel thread. For now, though, I have fixed the issue by moving
dynamic sysctl variable creation for these two drivers to a task queue
running in a kernel thread.
The existing task queues (taskqueue_swi and taskqueue_swi_giant) run in
software interrupt handlers, which wouldn't fix the problem at hand. So I
have created a new task queue, taskqueue_thread, that runs inside a kernel
thread. (It also runs outside of Giant -- clients must explicitly acquire
and release Giant in their taskqueue functions.)
scsi_cd.c: Remove sysctl variable creation code from cdregister(), and
move it to a new function, cdsysctlinit(). Queue
cdsysctlinit() to the taskqueue_thread taskqueue once we
have fully registered the cd(4) driver instance.
scsi_da.c: Remove sysctl variable creation code from daregister(), and
move it to move it to a new function, dasysctlinit().
Queue dasysctlinit() to the taskqueue_thread taskqueue once
we have fully registered the da(4) instance.
taskqueue.h: Declare the new taskqueue_thread taskqueue, update some
comments.
subr_taskqueue.c:
Create the new kernel thread taskqueue. This taskqueue
runs outside of Giant, so any functions queued to it would
need to explicitly acquire/release Giant if they need it.
cd.4: Update the cd(4) man page to talk about the minimum command
size sysctl/loader tunable. Also note that the changer
variables are available as loader tunables as well.
da.4: Update the da(4) man page to cover the retry_count,
default_timeout and minimum_cmd_size sysctl variables/loader
tunables. Remove references to /dev/r???, they aren't used
any longer.
cd.9: Update the cd(9) man page to describe the CD_Q_10_BYTE_ONLY
quirk.
taskqueue.9: Update the taskqueue(9) man page to describe the new thread
task queue, and the taskqueue_swi_giant queue.
MFC after: 3 days
2003-09-03 04:46:28 +00:00
|
|
|
.Nm
|
|
|
|
driver will default to using at least 10 byte CDBs.
|
|
|
|
If a 6 byte READ or WRITE fails with an ILLEGAL REQUEST error, the
|
|
|
|
.Nm
|
|
|
|
driver will then increase the default CDB size for the device to 10 bytes and
|
|
|
|
retry the command.
|
|
|
|
CDB size is always
|
|
|
|
chosen as the smallest READ/WRITE CDB that will satisfy the specified minimum
|
|
|
|
command size, and the LBA and length of the READ or WRITE in question.
|
|
|
|
(e.g., a write to an LBA larger than 2^32 will require a 16 byte CDB.)
|
|
|
|
.El
|
1995-01-25 09:18:56 +00:00
|
|
|
.Sh NOTES
|
1999-04-30 06:37:16 +00:00
|
|
|
If a device becomes invalidated (media is removed, device becomes unresponsive)
|
1998-10-16 03:28:12 +00:00
|
|
|
the disklabel and information held within the kernel about the device will
|
2003-06-28 23:53:39 +00:00
|
|
|
be invalidated.
|
|
|
|
To avoid corruption of a newly inserted piece of media or
|
1998-10-16 03:28:12 +00:00
|
|
|
a replacement device, all accesses to the device will be discarded until
|
2003-06-28 23:53:39 +00:00
|
|
|
the last file descriptor referencing the old device is closed.
|
|
|
|
During this period, all new open attempts will be rejected.
|
1995-01-25 09:18:56 +00:00
|
|
|
.Sh FILES
|
2006-09-18 15:24:20 +00:00
|
|
|
.Bl -tag -width ".Pa /dev/da*" -compact
|
2005-11-29 16:51:49 +00:00
|
|
|
.It Pa /dev/da*
|
|
|
|
SCSI disk device nodes
|
1995-01-25 09:18:56 +00:00
|
|
|
.El
|
|
|
|
.Sh DIAGNOSTICS
|
|
|
|
None.
|
|
|
|
.Sh SEE ALSO
|
2012-02-09 04:37:30 +00:00
|
|
|
.Xr ada 4 ,
|
2010-03-04 11:09:49 +00:00
|
|
|
.Xr cam 4 ,
|
2005-11-29 16:51:49 +00:00
|
|
|
.Xr geom 4 ,
|
|
|
|
.Xr bsdlabel 8 ,
|
1999-08-09 02:35:55 +00:00
|
|
|
.Xr fdisk 8
|
1995-01-25 09:18:56 +00:00
|
|
|
.Sh HISTORY
|
|
|
|
The
|
|
|
|
.Nm
|
1998-10-16 03:28:12 +00:00
|
|
|
driver was written for the
|
|
|
|
.Tn CAM
|
|
|
|
.Tn SCSI
|
2000-05-12 08:32:56 +00:00
|
|
|
subsystem by
|
2000-05-12 09:10:40 +00:00
|
|
|
.An Justin T. Gibbs .
|
1998-10-16 03:28:12 +00:00
|
|
|
Many ideas were gleaned from the
|
|
|
|
.Nm sd
|
|
|
|
device driver written and ported from
|
1996-01-18 21:36:18 +00:00
|
|
|
.Tn Mach
|
1998-10-16 03:28:12 +00:00
|
|
|
2.5
|
2000-05-12 09:10:40 +00:00
|
|
|
by
|
|
|
|
.An Julian Elischer .
|