Porting OpenBSD's sysctl hw.sensors framework to FreeBSD

[John Baldwin]

On Saturday 14 July 2007 12:25:39 am Constantine A. Murenin wrote:
> On 13/07/2007 12:52, John Baldwin wrote:
> 
> > On Friday 13 July 2007 11:48:19 am Constantine A. Murenin wrote:
> > 
> >>On 12/07/2007 14:04, John Baldwin wrote:
> >>
> >>
> >>>On Thursday 12 July 2007 03:00:08 am Alexander Leidinger wrote:
> >>>
> >>>
> >>>>Quoting John Baldwin <jhb at freebsd.org> (from Wed, 11 Jul 2007 
> >>>
> >>>11:45:26 -0400):
> >>>
> >>>
> >>>>>On Wednesday 11 July 2007 07:49:59 am Alexander Leidinger wrote:
> >>>>
> >>>>>>On the other hand you don't want to allow an userland tool to directly
> >>>>>>mess around with the registers on your RAID or NIC to get some 
status...
> >>>>>
> >>>>>Err, that's how all the RAID utilities I've used work.  They send 
> > 
> > firmware
> > 
> >>>>>commands from userland and parse the replies in userland.  One 
exception 
> >>>
> >>>I've
> >>>
> >>>
> >>>>That's sad... they should provide this functionality in the driver  
> >>>>instead, it would allow to use access restrictions for some parts.
> >>>
> >>>
> >>>Not really, it avoids having to duplicate a lot of work in drivers that 
> > 
> > can be 
> > 
> >>>written once in a cross-platform userland utility.  Drivers aren't really 
> > 
> > the 
> > 
> >>>place to be monitoring raid status sending pages, e-mails, etc.  It's 
best 
> > 
> > to 
> > 
> >>>let userland invoke sendmail, not the kernel. :)
> >>
> >>John, I'm sorry to disappoint you, but RAID drivers in OpenBSD don't 
> >>implement SMTP and don't do emails, they only provide updates to the 
> >>sensors framework when there are some changes in the state of the 
drive. :)
> >>
> >>sensorsd(8) is used to send alerts and emails based on the information 
> >>from the sensors framework, and user configuration.
> >>
> >>bioctl(8) is used to configure RAID for _all drivers_. There are no 
> >>separate utilities for RAID configuration based on brand-name, just like 
> >>nowadays there are no separate utilities for configuring Ethernet 
> >>adapters. [0]
> > 
> > 
> > According to the various manpages on www.openbsd.org you cannot configure 
> > arrays on the OS for at least mfi(4), ciss(4), twe(4), mpi(4) (like mpt(4) 
in 
> > FreeBSD) or ami(4) (like amr(4) in FreeBSD).  You can only do monitoring 
via 
> > hw.sensors for ciss(4) and ami(4), and the example for monitoring ami(4) 
in 
> > the manpage shows that you can only get volume level data, and as a 
_string_ 
> > and that you can't get backing physical drive status to know which 
physical 
> > drive has failed and needs to be replaced:
> > 
> >            $ sysctl hw.sensors.ami0
> >            hw.sensors.ami0.drive0=online (sd0), OK
> >            hw.sensors.ami0.drive1=degraded (sd1), WARNING
> >            hw.sensors.ami0.drive2=failed (sd2), CRITICAL
> 
> I'm not an expert on RAID monitoring and rebuilding, so I don't think I 
> can answer your questions about bioctl(8). You might want to refer to a 
> presentation that was done at BSDCan 2006 by David Gwynne. [b]

I've gained some recent experience in a production environment. :)

> However, I can tell you that in this sysctl(8) output that you've 
> quoted, "online" etc and "OK" etc fields are represented as enums (in 
> sensor datastructure), not strings. I trust that bioctl(8) gives further 
> status on which exact drive has failed, again, see dlg's presentation. 
> (Note that the sensors part of that presentation is now a bit outdated.)
> 
> As far as RAID drivers providing sensors are concerned -- a grep for 
> SENSOR_DRIVE_ONLINE reveals that it is being referenced from ami(4), 
> arc(4), ciss(4), mfi(4) and softraid(4). From what I could see in the 
> man pages, mpi(4) chips usually don't provide any raid functionality and 
> twe(4) lacks programming documentation from the manufacturer, thus 
> unavailability of RAID sensors from those two drivers doesn't come as a 
> surprise. ;)

Some mpi(4) do provide RAID0 and RAID1.  Usually mpi(4) is used as a SAS HBA, 
but some versions of the chip do support limited RAID.  While the mfi(4) 
driver probably has volume-level data, I doubt it has physical drive-level 
data as FreeBSD's driver doesn't either.  Note that there are 3rd party tools 
(megarc, MegaCli, the arcmsr (I assume that's arc(4) in openbsd) tool, 
3ware's tools) that are available, but they do their work in userland making 
use of an ioctl to send requests to the firmware.

-- 
John Baldwin