From owner-cvs-all@FreeBSD.ORG Wed Oct 17 14:32:51 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 7A45016A418; Wed, 17 Oct 2007 14:32:51 +0000 (UTC) (envelope-from netchild@freebsd.org) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id E55E213C480; Wed, 17 Oct 2007 14:32:50 +0000 (UTC) (envelope-from netchild@freebsd.org) Received: from outgoing.leidinger.net (p54A548C8.dip.t-dialin.net [84.165.72.200]) by redbull.bpaserver.net (Postfix) with ESMTP id C0C862E308; Wed, 17 Oct 2007 16:32:08 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 1E01F5B480D; Wed, 17 Oct 2007 16:31:03 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.14.1/8.13.8/Submit) id l9HEV2vN095200; Wed, 17 Oct 2007 16:31:02 +0200 (CEST) (envelope-from netchild@FreeBSD.org) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Wed, 17 Oct 2007 16:31:02 +0200 Message-ID: <20071017163102.jkl3sdzww8wkscw0@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Wed, 17 Oct 2007 16:31:02 +0200 From: Alexander Leidinger To: John Baldwin References: <200710161702.00008.jhb@freebsd.org> <471537CA.9080807@FreeBSD.org> <200710170907.07832.jhb@freebsd.org> In-Reply-To: <200710170907.07832.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-12.804, required 8, BAYES_00 -15.00, J_CHICKENPOX_27 0.60, MIME_QP_LONG_LINE 1.40, RDNS_DYNAMIC 0.10, SARE_FROM_SPAM_WORD3 0.10) X-BPAnet-MailScanner-From: netchild@freebsd.org X-Spam-Status: No Cc: Scott Long , src-committers@FreeBSD.org, 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: Wed, 17 Oct 2007 14:32:51 -0000 Quoting John Baldwin (from Wed, 17 Oct 2007 09:07:06 -0400= ): > On Tuesday 16 October 2007 06:14:34 pm Constantine A. Murenin wrote: >> On 16/10/2007 17:01, John Baldwin wrote: >> > Basically, by having so little data in hw.sensors if I had to write a R= AID >> > monitoring daemon I would just not use hw.sensors since it's =20 >> easier for me to >> > figure out the simple status myself based on the other state I =20 >> already have >> > to track (unless you write an event-driven daemon based on =20 >> messages posted by >> > the firmware in which case again you wouldn't use hw.sensors for =20 >> that either). >> >> There is no other daemon that you'd need, you'd simply use sensorsd for >> this. You could write a script that would be executed by sensorsd if a >> certain logical disc drive sensor changes state, and then this script >> would call the bio framework and give you additional details on why the >> state was changed. > > That's actually not quite good enough as, for example, I want to keep yell= ing > about a busted volume on a periodic basis until its fixed. Also, =20 > having a volume > change state doesn't tell me if a drive was pulled. On at least one RAID > controller firmware I am familiar with, the only way you can figure =20 > this out is > to keep track of which drives are currently present with a =20 > generation count and > use that to determine when a drive goes away. Even my monitoring daemon f= or > ata-raid has to do this since the ata(4) driver just detaches and =20 > removes a drive > when it fails and you have no way to figure out which drive died as =20 > the kernel > thinks that drive no longer exists. Note, talking about interaction with bio or similar is not productive =20 ATM. On Sunday I had a discussion with scottl and he identified some =20 things with bio which don't make it a good choice for FreeBSD. =20 Unfortunately I didn't had time to take it off the ideas list so far. =20 Scott also agreed to come up with a description for a similar =20 framework that is is usable with our RAID drivers. Bye, Alexander. --=20 http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 Mother is far too clever to understand anything she does not like. =09=09-- Arnold Bennett