Original author(s) | Marco Peereboom (2005) |
---|---|
Developer(s) | The OpenBSD Project |
Initial release | 23 August 2005 |
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.
[1]
[2] 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.
[3]
[4]
[5]
[6]
[7] 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.
[4] Interfacing between the kernel and userland is performed through the
ioctl
system call through the /dev/bio
pseudo-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 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. [9]
In the commentary to the 3.8 release, [9] 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). [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 card
BIOS 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 called mfiutil
, mptutil
, mpsutil
/mprutil
and sesutil
,
[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 to
code bloat, not to mention any additional drivers for which no such tool even exists as
open-source software at all.
[17]
In OpenBSD 6.4 (2018), a dozen of drivers register with the bio framework.
[1]
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 [4] and sysmon envsys with envstat and powerd in NetBSD. [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, both
SCSI Enclosure Services (SES)
[21] and
SAF-TE
[22] 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,
[4] and can be monitored through familiar tools like
sysctl,
SNMP and
sensorsd.
As of 2019 [update], 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; [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 the code bloat and the number of source 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
Original author(s) | Marco Peereboom (2005) |
---|---|
Developer(s) | The OpenBSD Project |
Initial release | 23 August 2005 |
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.
[1]
[2] 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.
[3]
[4]
[5]
[6]
[7] 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.
[4] Interfacing between the kernel and userland is performed through the
ioctl
system call through the /dev/bio
pseudo-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 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. [9]
In the commentary to the 3.8 release, [9] 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). [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 card
BIOS 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 called mfiutil
, mptutil
, mpsutil
/mprutil
and sesutil
,
[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 to
code bloat, not to mention any additional drivers for which no such tool even exists as
open-source software at all.
[17]
In OpenBSD 6.4 (2018), a dozen of drivers register with the bio framework.
[1]
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 [4] and sysmon envsys with envstat and powerd in NetBSD. [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, both
SCSI Enclosure Services (SES)
[21] and
SAF-TE
[22] 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,
[4] and can be monitored through familiar tools like
sysctl,
SNMP and
sensorsd.
As of 2019 [update], 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; [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 the code bloat and the number of source 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