| Original author(s) | Marco Peereboom (2005) |
|---|---|
| Developer(s) | TheOpenBSD Project |
| Initial release | 23 August 2005; 19 years ago (2005-08-23) |
| Repository | /sbin/bioctl |
| Written in | C |
| Operating system | OpenBSD since 3.8 (2005);NetBSD since 4.0 (2007) |
| Type | RAID management andsystem monitoring |
| Licence | BSD licence |
| Website | bioctl(8) |
Thebio(4)pseudo-device driver and thebioctl(8) utility implement a genericRAID volume management interface inOpenBSD andNetBSD.[1][2] The idea behind this software is similar toifconfig, where a single utility from theoperating system can be used to control anyRAID controller using a genericinterface, instead of having to rely on manyproprietary and custom RAID management utilities specific for each given hardware RAID manufacturer.[3][4][5][6][7] Features include monitoring of the health status of the arrays, controlling identification through blinking theLEDs and managing of sound alarms, and specifyinghot spare disks. Additionally, thesoftraid configuration in OpenBSD is delegated to bioctl as well; whereas the initial creation of volumes and configuration of hardware RAID is left to cardBIOS as non-essential after the operating system has already been booted.[4] Interfacing between the kernel and userland is performed through theioctl system call through the/dev/biopseudo-device.
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.[5][8][9]The development took place during a time of controversy whereAdaptec 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.[9]
In the commentary to the 3.8 release,[9] the developers express theirony of hardwareRAID controllers' supposed purpose of providing reliability, throughredundancy and repair, whereas in reality many vendors expectsystem administrators to install and depend on hugebinary blobs in order to be assess volume health and service theirdisk arrays.Specifically, OpenBSD is making a reference to themodus operandi ofFreeBSD, where the documentation of the aac(4) driver for Adaptec specifically suggests enablingLinux 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 theproprietary tools may have expired).[10][11][12]
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 cardBIOS was never kept secret from any bio/bioctl announcement.[4][5]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[ref], FreeBSD includes separate device-specific utilities calledmfiutil,mptutil,mpsutil/mprutil andsesutil,[13][14][15][16], each of which provides many options with at least subtle differences in the interface for configuration and management of the controllers, contributes tocode bloat, not to mention any additional drivers for which no such tool even exists asopen-source software at all.[17]In OpenBSD 6.4 (2018), a dozen of drivers register with the bio framework.[1]
drive sensorsMonitoring of the state of each logical drive is also duplicated into thehardware monitoring frameworks and their corresponding utilities on both systems where bioctl is available —hw.sensors with sensorsd in OpenBSD[4] and sysmonenvsys with envstat and powerd inNetBSD.[18] 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.[19] More drivers are being converted to use the bio and sensors frameworks with each release.[20]
In OpenBSD, bothSCSI Enclosure Services (SES)[21] andSAF-TE[22] are supported since OpenBSD 3.8 (2005) as well, both of which featureLED blinking through bio and bioctl (by implementing theBIOCBLINKioctl), helpingsystem 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 thehw.sensors framework in OpenBSD,[4] and can be monitored through familiar tools likesysctl,SNMP andsensorsd.
As of 2019[update], inNetBSD, an older SES/SAF-TE driver fromNASA from 2000 is still in place, which is not integrated with bio orenvsys, but has its owndevice files with a uniqueioctl interface, featuring its own custom SCSI-specific userland tooling;[23][24] 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 thecode bloat and the number ofsource lines of code.
{{cite web}}: CS1 maint: numeric names: authors list (link)Hackers of the Lost RAID
If the kernel is compiled with the COMPAT_LINUX option, or the aac_linux.ko and linux.ko modules are loaded,...
{{cite web}}: CS1 maint: bot: original URL status unknown (link)drivers designed for binary only Linux RAID management tools
RAID management is almost completely undocumented
