cvs commit: src/etc Makefile sensorsd.conf src/etc/defaults
rc.conf src/etc/rc.d Makefile sensorsd src/lib/libc/gen
sysctl.3 src/sbin/sysctl sysctl.8 sysctl.c src/share/man/man5
rc.conf.5 src/share/man/man9 Makefile sensor_attach.9 src/sys/conf f
jhb at FreeBSD.org
Tue Oct 16 14:28:02 PDT 2007
On Monday 15 October 2007 10:57:48 pm Constantine A. Murenin wrote:
> On 15/10/2007, John Baldwin <jhb at freebsd.org> wrote:
> > On Monday 15 October 2007 09:43:21 am Alexander Leidinger wrote:
> > > Quoting Scott Long <scottl at samsco.org> (from Mon, 15 Oct 2007
> > 01:47:59 -0600):
> > >
> > > > Alexander Leidinger wrote:
> > > >> Quoting Poul-Henning Kamp <phk at phk.freebsd.dk> (from Sun, 14 Oct
> > > >> 2007 17:54:21 +0000):
> > >
> > > >>> listen to the various mumblings about putting RAID-controller status
> > > >>> under sensors framework.
> > > >>
> > > >> What's wrong with this? Currently each RAID driver has to come up
> > > >> with his own way of displaying the RAID status. It's like saying
> > > >> that each network driver has to implement/display the stuff you can
> > > >> see with ifconfig in its own way, instead of using the proper
> > > >> network driver interface for this.
> > > >>
> > > >
> > > > For the love of God, please don't use RAID as an example to support
> > > > argument for the sensord framework. Representing RAID state is
> > > > orders of magnitude more involved than representing network state.
> > > > There are also landmines in the OpenBSD bits of RAID support that are
> > > > best left out of FreeBSD, unless you like alienating vendors and
> > > > legal action. Leave it alone. Please. I don't care what you do with
> > > > lmsensors or cpu power settings or whatever. Leave RAID out of it.
> > >
> > > Talking about RAID status is not talking about alienating vendors. I
> > > don't talk about alienating vendors and I don't intent to do. You may
> > > not be able to display a full blown RAID status with the sensors
> > > framework, but it allows for a generic "wors/works not" or
> > > "OK/degraded" status display in drivers we have the source for. This
> > > is enough for status monitoring (e.g., nagios).
> > As I mentioned in the thread on arch@ where people brought up objections
> > were apparently completely ignored, this is far from useful for RAID
> > monitoring. For example, if my RAID is down, which disk do I need to
> > replace? Again, all this was covered earlier and (apparently) ignored.
> > Also, what strikes me as odd is that I didn't see this patch posted again
> > review this time around before it was committed.
> This has been addressed back in July. You'd use bioctl to see which
> exact disc needs to be replaced. Sensorsd is intended for an initial
> alert about something being wrong.
In July you actually said you weren't sure about bioctl(8). :) But also, this
model really isn't very sufficient since it doesn't handle things like drives
going away, etc. You really need to maintain a decent amount of state to
keep all that, and this is far easier done in userland rather than in the
kernel. However, you can choose to ignore real-world experience if you
Basically, by having so little data in hw.sensors if I had to write a RAID
monitoring daemon I would just not use hw.sensors since it's easier for me to
figure out the simple status myself based on the other state I already have
to track (unless you write an event-driven daemon based on messages posted by
the firmware in which case again you wouldn't use hw.sensors for that either).
More information about the cvs-src