Software:bioctl

Short description: Generic RAID volume management

bioctl

Original author(s)	Marco Peereboom (2005)
Developer(s)	The OpenBSD Project
Initial release	23 August 2005 (2005-08-23)
Repository	/sbin/bioctl
Written in	C
Operating system	OpenBSD since 3.8 (2005); NetBSD since 4.0 (2007)
Type	RAID management and system monitoring
Licence	BSD licence
Website	bioctl(8)

The bio(4) pseudo-device driver and the bioctl(8) utility implement a generic RAID volume management interface in OpenBSD and NetBSD. The idea behind this software is similar to ifconfig, where a single utility from the operating system can be used to control any RAID controller using a generic interface, instead of having to rely on many proprietary and custom RAID management utilities specific for each given hardware RAID manufacturer. Features include monitoring of the health status of the arrays, controlling identification through blinking the LEDs and managing of sound alarms, and specifying hot spare disks. Additionally, the softraid configuration in OpenBSD is delegated to bioctl as well; whereas the initial creation of volumes and configuration of hardware RAID is left to card BIOS as non-essential after the operating system has already been booted. Interfacing between the kernel and userland is performed through the ioctl system call through the /dev/bio pseudo-device.

Overview

The bio/bioctl subsystem is deemed to be an important part in OpenBSD's advocacy for open hardware documentation, and the 3.8 release title and the titular song were dedicated to the topic — Hackers of the Lost RAID. The development took place during a time of controversy where Adaptec refused to release appropriate hardware documentation that was necessary in order for the make the aac(4) driver work reliably, which followed with OpenBSD disabling support for the driver.

In the commentary to the 3.8 release, the developers express the irony of hardware RAID controllers' supposed purpose of providing reliability, through redundancy and repair, whereas in reality many vendors expect system administrators to install and depend on huge binary blobs in order to be assess volume health and service their disk arrays. Specifically, OpenBSD is making a reference to the modus operandi of FreeBSD, where the documentation of the aac(4) driver for Adaptec specifically suggests enabling Linux compatibility layer in order to use the management utilities (where the documentation even fails to explain where exactly these utilities must be obtained from, or which versions would be compatible, evidently because the proprietary tools may have expired).

Likewise, OpenBSD developers intentionally chose to concentrate on supporting only the most basic features of each controller which are uniform across all the brands and variations; specifically, the fact that initial configuration of each controller must still be made through card BIOS was never kept secret from any bio/bioctl announcement. This can be contrasted with the approach taken by FreeBSD, for example, where individual utilities exist for several independent RAID drivers, and the interface of each utility is independent of one another; specifically, (As of March 2019), FreeBSD includes separate device-specific utilities called mfiutil, mptutil, mpsutil/mprutil and sesutil,, each of which provides many options with at least subtle differences in the interface for configuration and management of the controllers, contributes to code bloat, not to mention any additional drivers for which no such tool even exists as open-source software at all. In OpenBSD 6.4 (2018), a dozen of drivers register with the bio framework.

The drive sensors

Monitoring of the state of each logical drive is also duplicated into the hardware monitoring frameworks and their corresponding utilities on both systems where bioctl is available — hw.sensors with sensorsd in OpenBSD and sysmon envsys with envstat and powerd in NetBSD. For example, on OpenBSD since 4.2 release, the status of the drive sensors could be automatically monitored simply by starting sensorsd without any specific configuration being required. More drivers are being converted to use the bio and sensors frameworks with each release.

SES/SAF-TE

In OpenBSD, both SCSI Enclosure Services (SES) and SAF-TE are supported since OpenBSD 3.8 (2005) as well, both of which feature LED blinking through bio and bioctl (by implementing the BIOCBLINK ioctl), helping system administrators identify devices within the enclosures to service. Additionally, both the SES and SAF-TE drivers in OpenBSD feature support for a combination of temperature and fan sensors, PSU, doorlock and alarm indicators; all of this auxiliary sensor data is exported into the hw.sensors framework in OpenBSD, and can be monitored through familiar tools like sysctl, SNMP and sensorsd.

(As of 2019), in NetBSD, an older SES/SAF-TE driver from NASA from 2000 is still in place, which is not integrated with bio or envsys, but has its own device files with a unique ioctl interface, featuring its own custom SCSI-specific userland tooling; this older implementation was also available in OpenBSD between 2000 and 2005, and was removed 2005 (together with its userland tools) just before the new leaner bio- and hw.sensors-based alternative drivers were introduced; SES and SAF-TE are now kept as two separate drivers in OpenBSD, but don't require any separate custom userland utilities anymore, reducing the code bloat and the number of source lines of code.