ATA_QC_COMPLETE(9) libata Library ATA_QC_COMPLETE(9)NAME
ata_qc_complete - Complete an active ATA command
SYNOPSIS
void ata_qc_complete(struct ata_queued_cmd * qc);
ARGUMENTS
qc
Command to complete
DESCRIPTION
Indicate to the mid and upper layers that an ATA command has completed, with either an ok or not-ok status.
Refrain from calling this function multiple times when successfully completing multiple NCQ commands. ata_qc_complete_multiple should be
used instead, which will properly update IRQ expect state.
LOCKING
spin_lock_irqsave(host lock)
AUTHOR
Jeff Garzik
Author.
COPYRIGHT Kernel Hackers Manual 3.10 June 2014 ATA_QC_COMPLETE(9)
Check Out this Related Man Page
ADA(4) BSD Kernel Interfaces Manual ADA(4)NAME
ada -- ATA Direct Access device driver
SYNOPSIS
device ada
DESCRIPTION
The ada driver provides support for direct access devices, implementing the ATA command protocol, that are attached to the system through a
host adapter supported by the CAM subsystem.
The host adapter must also be separately configured into the system before an ATA direct access device can be configured.
COMMAND QUEUING
Command queueing allows the device to process multiple transactions concurrently, often re-ordering them to reduce the number and length of
seeks. ATA defines two types of queueing: TCQ (Tagged Command Queueing, PATA legacy) and NCQ (Native Command Queueing, SATA). The ada
device driver takes full advantage of NCQ, when supported. To ensure that transactions to distant parts of the media, which may be deferred
indefinitely by servicing requests closer to the current head position, are completed in a timely fashion, an ordered transaction is sent
every 7 seconds during continuous device operation.
CACHE EFFECTS
Many direct access devices are equipped with read and/or write caches. Parameters affecting the device's cache are reported in device IDEN-
TIFY data and 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 trans-
parent 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 write cache can greatly decrease the latency of write operations and allows the device to reorganize writes to increase efficiency and
performance. 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 system is non-deterministic and can cause corruption. Most
devices age write transactions to limit the vulnerability to a few transactions recently reported as complete, but it is nonetheless recom-
mended that systems with write cache enabled devices reside on an Uninterruptible Power Supply (UPS). The ada 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.
SYSCTL VARIABLES
The following variables are available as both sysctl(8) variables and loader(8) tunables:
kern.cam.ada.retry_count
This variable determines how many times the ada driver will retry a READ or WRITE command. This does not affect the number of retries
used during probe time or for the ada driver dump routine. This value currently defaults to 4.
kern.cam.ada.default_timeout
This variable determines how long the ada driver will wait before timing out an outstanding command. The units for this value are sec-
onds, and the default is currently 30 seconds.
kern.cam.ada.spindown_shutdown
This variable determines whether to spin-down disks when shutting down. Set to 1 to enable spin-down, 0 to disable. The default is cur-
rently enabled.
FILES
/dev/ada* ATA device nodes
SEE ALSO ad(4), ahci(4), cam(4), da(4), siis(4)HISTORY
The ada driver first appeared in FreeBSD 8.0.
AUTHORS
Alexander Motin <mav@FreeBSD.org>
BSD October 24, 2010 BSD