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 files ...

[John Baldwin]

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 your
> > argument for the sensord framework.  Representing RAID state is several
> > 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 risking
> > 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 that 
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 for 
review this time around before it was committed.

-- 
John Baldwin