ADA(4)

💖 ADA(4) — the ATA Direct Access device driver, bestie edition 💖

okay so like. this is ada(4), straight out of the Kernel Interfaces Manual. it's a kernel interface page, so it's giving very much "device driver lore" and honestly? we're obsessed. 🦋

---

✨ NAME ✨

ada — the ATA Direct Access device driver. that's it, that's the name, no notes. 💅

---

✨ SYNOPSIS ✨

device ada

yes girl, one line. iconic behavior. 👑

---

🌸 DESCRIPTION 🌸

so the ada driver is the one that provides support for direct access devices — aka the ones implementing the ATA command protocol — and those devices have to be attached to your system through a host adapter that's supported by the CAM subsystem. that's the whole vibe check right there. 🎀

and like, important: the host adapter itself has to be separately configured into the system first, before an ATA direct access device can even be configured. it's giving "you can't sit with us until the adapter sits with us first". no cap. 💀

---

🔥 COMMAND QUEUING 🔥

so command queuing lets the device process multiple transactions concurrently — and often it'll re-order them to cut down on the number and length of seeks. efficiency queen. ✨

ATA defines two types of queuing, and here they are, no gatekeeping:

• TCQ — Tagged Command Queuing, the PATA legacy one 🕰️
• NCQ — Native Command Queuing, the SATA one ⚡

the ada device driver takes full advantage of NCQ when it's supported. periodt. 💅

now here's the clever bit: transactions headed to distant parts of the media could get deferred indefinitely if the device keeps servicing requests closer to the current head position. to make sure those far-away requests still complete in a timely fashion, an ordered transaction gets sent every 7 seconds during continuous device operation. bestie is keeping everyone fed. 🍓

---

💜 CACHE EFFECTS 💜

lots of direct access devices come equipped with read and/or write caches, and the parameters affecting a device's cache are reported in the device's IDENTIFY data. you can peek at them and modify them with the camcontrol(8) utility. 🧚

🌈 the read cache

the read cache stores data from device-initiated read ahead operations plus frequently used data. it's transparent to the user and you can enable it with no adverse effect whatsoever. most devices with a read cache ship from the factory with it already enabled. slay, honestly. ✨

💀 the write cache — okay this one's serious

the write cache can greatly decrease the latency of write operations, and it lets the device reorganize writes to boost efficiency and performance. but — and I need you to hear me on this —

that performance gain comes at a price. 😭

if the device loses power while its cache contains uncommitted write operations, those writes are GONE. lost. not coming back. and the effect of losing write transactions on a file system is non-deterministic and can cause corruption. 💀💀💀

most devices age write transactions to limit the vulnerability to just a few transactions recently reported as complete — but even so, it is recommended that systems with write cache enabled devices reside on an Uninterruptible Power Supply (UPS). fr fr, plug in the UPS. 🔌

good news though: the ada device driver makes sure the cache and media are synchronized on final close of the device, or on an unexpected shutdown (panic) event. that means it's 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. two for one, we love a multitasker. 💅

• kern.cam.ada.retry_count — this one decides how many times the ada driver will retry a READ or WRITE command. heads up: it does not affect the number of retries used during probe time, and it doesn't affect the ada driver dump routine either. the value currently defaults to 4.
• kern.cam.ada.default_timeout — this decides how long the ada driver waits before timing out an outstanding command. units are seconds, and the default is currently 30 seconds.
• kern.cam.ada.spindown_shutdown — this decides whether to spin-down disks when shutting down. set to 1 to enable spin-down, 0 to disable. the default is currently enabled.
• kern.cam.sort_io_queue and kern.cam.ada.X.sort_io_queue — these decide 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.
• kern.cam.ada.read_ahead, kern.cam.ada.X.read_ahead, kern.cam.ada.write_cache, and kern.cam.ada.X.write_cache — these decide whether device read-ahead and write caches should be enabled globally or per-device, or disabled. set to 1 to enable write cache, 0 to disable, -1 to leave it as-is.

⚠️ values modified at runtime take effect only after a device reset (using the reset subcommand of camcontrol(8)). because of that, this setting should be changed in /boot/loader.conf instead of /etc/sysctl.conf. the global default is currently 1. the per-device default is to leave it as-is (meaning: follow the global setting).

---

🎀 FILES 🎀

• /dev/ada* — ATA device nodes

---

🦋 SEE ALSO 🦋

ahci(4), cam(4), da(4), mvs(4), nda(4), siis(4)

go read your friends, king. 👑

---

👑 HISTORY 👑

the ada driver first appeared in FreeBSD 8.0. a true OG. 🌈

---

💖 AUTHORS 💖

Alexander Motin <mav@FreeBSD.org> — thank you for your service, we are literally so grateful. 🫶

---

and that's the whole page, bestie!! this one comes to you from Debian, dated December 20, 2017 — so like, vintage but make it functional. ✨💅✨