From owner-cvs-all@FreeBSD.ORG Tue Oct 16 02:57:50 2007 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C565416A421 for ; Tue, 16 Oct 2007 02:57:50 +0000 (UTC) (envelope-from mureninc@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.232]) by mx1.freebsd.org (Postfix) with ESMTP id 310D613C46B for ; Tue, 16 Oct 2007 02:57:49 +0000 (UTC) (envelope-from mureninc@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so895859wra for ; Mon, 15 Oct 2007 19:57:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; bh=4ox01uisCJhzkf0Qc9tRsOtQswlLEkSIyJWPfPPQ9Ds=; b=LjSQdR7c74yTw5lST2v0VNX5eF77MMebPn/xpPEiJSJFeALiItAP6q45bkAg8vuTElKrB9OfJKU1D7vKj70Mc2daqdiFEtpVZhHismYZMEeQCB4Wu0jQMkvhL/WCW4rTNP2iCijoPHNItIpx0kkFG3Ibka9BKXzg8w7jtieQXds= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=Cs833/Gl8qp1L52qowgVoYnp+CznP6q+Z4uXm/m1I+f2kGgB5SNO6mBJpEZZr+ih/gNT4gF+xoJEyDjZp+L2U90FqPV2mft0A1f9OF0FTNyBYTvsNNRLHQMfUhP+pYQQpkY+mrK9R5oT4pHbZlqzizTkKa8qWSFOkSJ5dQealtw= Received: by 10.90.89.5 with SMTP id m5mr9849838agb.1192503468835; Mon, 15 Oct 2007 19:57:48 -0700 (PDT) Received: by 10.90.78.10 with HTTP; Mon, 15 Oct 2007 19:57:48 -0700 (PDT) Message-ID: Date: Mon, 15 Oct 2007 22:57:48 -0400 From: "Constantine A. Murenin" To: "John Baldwin" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Scott Long , src-committers@freebsd.org, Alexander Leidinger , cvs-src@freebsd.org, cvs-all@freebsd.org, "Constantine A. Murenin" , Poul-Henning Kamp , Wilko Bulte Subject: Re: 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 X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 02:57:50 -0000 On 15/10/2007, John Baldwin wrote: > On Monday 15 October 2007 09:43:21 am Alexander Leidinger wrote: > > Quoting Scott Long (from Mon, 15 Oct 2007 > 01:47:59 -0600): > > > > > Alexander Leidinger wrote: > > >> Quoting Poul-Henning Kamp (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. 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. C.