CTL(4)

💖 NAME 💖

ctl — CAM Target Layer, aka the icon, the moment, the whole vibe ✨

---

🌸 SYNOPSIS 🌸

okay so if you wanna bake this driver right into your kernel, bestie, drop this line into your kernel configuration file:

device ctl

orrr, if you'd rather load it as a module at boot time (lowkey easier ngl), put this in loader.conf(5):

ctl_load="YES"

---

🦋 DESCRIPTION 🦋

The ctl subsystem is literally the SCSI target devices emulation queen 👑. She does all of this:

• Disk, CD-ROM and processor device emulation 💅
• Tagged queueing
• SCSI task attribute support (ordered, head of queue, simple tags)
• SCSI implicit command ordering support
• Full task management support (abort, query, reset, etc.) — she can abort things, periodt
• Support for multiple ports, initiators, targets and backing stores
• Support for VMWare VAAI and Microsoft ODX offload (COMPARE AND WRITE, XCOPY, POPULATE TOKEN/WRITE USING TOKEN, WRITE SAME and UNMAP) 🔥
• Persistent reservation support
• Extensive VPD/mode/log pages support
• Featured error reporting, error injection and basic SMART support
• High Availability clustering support with ALUA
• All I/O handled in-kernel, no userland context switch overhead — no context switching, no drama, no overhead, she's built different fr fr

The ctl subsystem also has multiple frontends so she can speak to everybody in their own love language 🫶, each one giving access via a different transport protocol and implementation:

• camsim — gives access for local system via virtual initiator mode CAM(4) SIM.
• camtgt — gives access for remote systems via target mode CAM(4) SIMs, such as Fibre Channel isp(4) and mpt(4).
• cfumass — gives access for remote systems via USB Mass Storage Class Bulk Only (BBB) Transport.
• ha — internal frontend used to receive requests from other node ports in High Availability cluster.
• ioctl — gives access for local user-level applications via ioctl(2) based API.
• iscsi — gives access for remote systems via the iSCSI protocol using cfiscsi(4).
• tpc — internal frontend used to receive requests from Third Party Copy engine, implementing copy offload operations.

And she's got two backends to create logical units using different kinds of backing stores, because obviously she needs options 💁‍♀️:

• block — stores data in ZFS ZVOLs, files or raw block devices.
• ramdisk — stores data in RAM, that makes it mostly useful for performance testing. Depending on configured capacity can work as black hole, thin or thick provisioned disk.

---

✨ SYSCTL VARIABLES ✨

These ones are available as both sysctl(8) variables and loader(8) tunables, so you can vibe with them however you like:

• kern.cam.ctl.debug — bit mask of enabled CTL log levels:
  • 1 — log commands with errors;
  • 2 — log all commands;
  • 4 — log data for commands other then READ/WRITE.

Defaults to 0.

• kern.cam.ctl.ha_id — specifies unique position of this node within High Availability cluster. Default is 0 — no HA, 1 and 2 — HA enabled at specified position.
• kern.cam.ctl.ha_mode — specifies High Availability cluster operation mode:
  • 0 — Active/Standby — primary node has backend access and processes requests, while secondary can only do basic LUN discovery and reservation;
  • 1 — Active/Active — both nodes have backend access and process requests, while secondary node synchronizes processing with primary one;
  • 2 — Active/Active — primary node has backend access and processes requests, while secondary node forwards all requests and data to primary one.

All above modes require established connection between HA cluster nodes. If connection is not configured, secondary node will report Unavailable state; if configured but not established — Transitioning state. Defaults to 0.

• kern.cam.ctl.ha_peer — string value, specifying method to establish connection to peer HA node. Can be "listen IP:port", "connect IP:port" or empty.
• kern.cam.ctl.ha_link — reports present state of connection between HA cluster nodes:
  • 0 — not configured;
  • 1 — configured but not established;
  • 2 — established.
• kern.cam.ctl.ha_role — specifies default role of this node:
  • 0 — primary;
  • 1 — secondary.

This role can be overridden on per-LUN basis using "ha_role" LUN option, so that for one LUN one node is primary, while for another — another. Role change from primary to secondary for HA modes 0 and 2 closes backends, the opposite change — opens. If there is no primary node (both nodes are secondary, or secondary node has no connection to primary one), secondary node(s) report Transitioning state. State with two primary nodes is illegal (split brain condition).

🚨 heads up bestie: two primary nodes = split brain = illegal, we do NOT do that here 💀

---

🎀 TUNABLE VARIABLES 🎀

These ones live as loader(8) tunables:

• kern.cam.ctl.max_luns — specifies the maximum number of LUNs we support, must be a power of 2. The default value is 1024.
• kern.cam.ctl.max_ports — specifies the maximum number of ports we support, must be a power of 2. The default value is 256.

🌟 reminder: power of 2, bestie. Not 1000. Not 1023. Power. Of. Two. ✨

---

🔗 SEE ALSO 🔗

cfiscsi(4), cfumass(4), ctladm(8), ctld(8), ctlstat(8)

---

📜 HISTORY 📜

The ctl subsystem first appeared in FreeBSD 9.1. a true 2012-era icon, she's been serving looks for years 💜

---

💜 AUTHORS 💜

The ctl subsystem was originally written by Kenneth Merry <ken@FreeBSD.org>. Later work was done by Alexander Motin <mav@FreeBSD.org>. legends, honestly 🫶

---

okay that's the whole page, you're so welcome 💖 this was the Debian build, dated March 29, 2017 — mwah, go slay some SCSI targets ✨👑