Date: Wed, 17 Oct 2007 16:31:02 +0200 From: Alexander Leidinger <netchild@FreeBSD.org> To: John Baldwin <jhb@FreeBSD.org> Cc: Scott Long <scottl@samsco.org>, src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, "Constantine A. Murenin" <cnst@FreeBSD.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Wilko Bulte <wb@freebie.xs4all.nl> 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 Message-ID: <20071017163102.jkl3sdzww8wkscw0@webmail.leidinger.net> In-Reply-To: <200710170907.07832.jhb@freebsd.org> References: <f34ca13c0710151957r75039ad9g5267f54cc15b5fe5@mail.gmail.com> <200710161702.00008.jhb@freebsd.org> <471537CA.9080807@FreeBSD.org> <200710170907.07832.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting John Baldwin <jhb@freebsd.org> (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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071017163102.jkl3sdzww8wkscw0>