DA(4)

💖 da(4) — SCSI Direct Access device driver 💖

okay bestie, gather round, because this is the manual page for da, the SCSI Direct Access device driver, and it is lowkey the moment. no cap. 🦋

---

✨ NAME ✨

da — SCSI Direct Access device driver. it's giving "the driver that talks to your disks". periodt. 💅

---

🌸 SYNOPSIS 🌸

device da

that's it. that's the whole vibe. add that line and you're in. 🎀

---

💜 DESCRIPTION 💜

so 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. and what's in the direct access class, you ask? 👀

• disk devices
• magneto-optical devices
• solid-state devices

all of them. the whole squad. 🫶

⚠️ but heads up: a SCSI Host adapter must also be separately configured into the system before a SCSI direct access device can be configured. no adapter, no device. the way that works is just... the way that works. 😭

---

🎀 CACHE EFFECTS 🎀

many direct access devices come equipped with read and/or write caches. and the parameters affecting the device's cache are stored in mode page 8, the caching control page. you can examine and modify mode pages via the camcontrol(8) utility. ✨

🌈 the read cache

the read cache is used to store data from device-initiated read ahead operations as well as frequently used data. and here's the slay part: the read cache is transparent to the user and can be enabled without any adverse effect. most devices with a read cache come from the factory with it enabled, iykyk.

want it off? set the RCD (Read Cache Disable) bit in the caching control mode page. boom. 🦋

🔥 the write cache

okay so the write cache can greatly decrease the latency of write operations and lets the device reorganize writes to increase efficiency and performance. iconic behavior. BUT — and this is a big but — 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 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 Supply (UPS). fr fr, get the 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. so you can pull the plug — but only after the OS says it halted. respect the order. 👑

the write cache can be enabled by setting the WCE (Write Cache Enable) bit in the caching control mode page. 💖

---

⭐ TAGGED QUEUING ⭐

the da device driver will take full advantage of the SCSI feature known as tagged queueing. and what does that do? it allows the device to process multiple transactions concurrently, often re-ordering them to reduce the number and length of seeks. multitasking queen. 👑

and 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. every 15 seconds. clockwork. ⏰

---

🦋 BAD BLOCK RECOVERY 🦋

Direct Access devices have the capability of mapping out portions of defective media. the media recovery parameters live in mode page 1, the Read-Write Error Recovery mode page.

the most important media remapping 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 factory with these features enabled. rude, honestly.

mode pages can be examined and modified via the camcontrol(8) utility. same utility, same slay. ✨

---

💅 KERNEL CONFIGURATION 💅

good news: it is only necessary to explicitly configure one da device. just one. because data structures are dynamically allocated as disks are found on the SCSI bus. the kernel handles the rest, bestie. no extra work. 🫶

---

👑 SYSCTL VARIABLES 👑

the following variables are available as both sysctl(8) variables and loader(8) tunables:

• kern.cam.da.retry_count — this variable determines how many times the da driver will retry a READ or WRITE command. note: this does not affect the number of retries used during probe time or for the da driver dump routine. this value currently defaults to 4.
• kern.cam.da.default_timeout — this variable determines how long the da driver will wait before timing out an outstanding command. the units for this value are seconds, and the default is currently 60 seconds.
• kern.cam.sort_io_queue
• kern.cam.da.X.sort_io_queue — these variables determine whether the request queue should be sorted trying to optimize head seeks. set to 1 to enable sorting, 0 to disable, -1 to leave it as-is. the default is sorting enabled for HDDs and disabled for SSDs. different devices, different vibes. 🌈
• kern.cam.da.X.delete_method — this variable specifies the method to handle BIO_DELETE requests:
  • ATA_TRIM — ATA TRIM via ATA COMMAND PASS THROUGH command,
  • UNMAP — UNMAP command,
  • WS16 — WRITE SAME(16) command with UNMAP flag,
  • WS10 — WRITE SAME(10) command with UNMAP flag,
  • ZERO — WRITE SAME(10) command without UNMAP flag,
  • DISABLE — disable BIO_DELETE support.
• kern.cam.da.X.minimum_cmd_size — this variable determines what the minimum READ/WRITE CDB size is for a given da unit. valid minimum command size values are 6, 10, 12 and 16 bytes. the default is 6 bytes.

and here's the lore on how it actually picks: the da driver issues a CAM Path Inquiry CCB at probe time to determine whether the protocol the device in question speaks (e.g. ATAPI) typically does not allow 6 byte commands. if it does not, the da driver will default to using at least 10 byte CDBs. and if a 6 byte READ or WRITE fails with an ILLEGAL REQUEST error, the da 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.) math is math. 🧚

---

🙈 NOTES 🙈

if a device becomes invalidated (media is removed, device becomes unresponsive) 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. and during this period, all new open attempts will be rejected. 🚫

💀 so like... yeah. close your fds. it's not a suggestion.

---

🍓 FILES 🍓

• /dev/da* — SCSI disk device nodes

---

🧚 DIAGNOSTICS 🧚

None.

literally none. nothing to report. the silence is deafening. 😌

---

💖 SEE ALSO 💖

ada(4), cam(4), geom(4), nda(4), gpart(8)

go read those too, bestie, they're all part of the extended universe. 🫶

---

🌟 HISTORY 🌟

the da driver was written for the CAM SCSI subsystem by Justin T. Gibbs. and many ideas were gleaned from the sd device driver written and ported from Mach 2.5 by Julian Elischer. legends only. 👑

---

and that's the whole page, babes — this one came from the Debian edition of the manual, dated December 20, 2017, and it's filed under DA(4). mwah, go format a disk responsibly. 💅✨🎀