FreeNAS & Sensors for FreeBSD

This WE I was told that FreeNAS seems to want to move from FreeBSD to Linux (since then it seems there could be a linux and a FreeBSD ver­sion). One of the reas­ons seems to be a miss­ing sensors frame­work.

As I was com­mit­ting a port of the OpenBSD sensors frame­work (pro­duced as part of the Google Sum­mer of Code 2007) to FreeBSD and had to re­move it af­ter­wards be­cause one com­mit­ter com­plained very loudly, I was asked what the status of this is.

The short status is: Nobody is do­ing some­thing about it.

Be­fore I ex­plain the long status, I give  a short over­view what this sensors frame­work is:

  • a ker­nel API which al­lows to add sensors
  • an in­ter­face for the user­land to query the sensor data
  • some ba­sic user­land code to show and log the sensor info

The API and the query in­ter­face are more or less in­de­pend­ent. For the user­land code it was more a log­ging in­fra­struc­ture than a real mon­it­or­ing solu­tion. The reason was the real mon­it­or­ing solu­tions already ex­ist (Nagios, sn­mpd, …) and can be ad­ap­ted to query the sensors. Ideally a query in user­land should be handled by a lib­rary in­stead of dir­ectly ac­cess­ing the sy­sctl in­ter­face, this way the kernel<->userland in­ter­face would be ab­strac­ted away (and could b re­placed as needs arise). This was not done, it was some­thing to be done later (Rome was not build in a day).

The user­land in­ter­face also only cared about dumb sensors (those which you need to query manu­ally to get the in­form­a­tion), smart sensors (those which are able to send events them­self) where not taken care about in the sense of really send­ing sensor-​triggered events, but the ker­nel API al­lowed to add such sensors. The sy­sctl in­ter­face has no way of send­ing events, but FreeBSD already has an event in­ter­face (devd is tak­ing care about it). It would have been not a prob­lem to send events via this chan­nel and let an user­land lib­rary take care about the de­liv­ery to­gether with other sensor-​data in user­land.

And now the long status is:

PHK com­plained loudly about it. First he said he did not look at it but he com­plained that is not good re­gard­less. After a lot of nag­ging from me he had a look at it and was not happy about the time stuff in it (short: the FreeBSD time­counter code is bet­ter). This was not a prob­lem in my opin­ion, we could have dis­abled this part without prob­lems. After such an of­fer from me, he com­plained that the sensors frame­work uses the sy­sctl in­ter­face in­stead of an entry in /​dev.

At this point in time already sev­eral user­land util­it­ies used the sy­sctl frame­work to query for status data in the ker­nel. So there was already pre­ced­ence for such an use of it. Later some more such uses where ad­ded too (e.g. the proc­stat stuff by core team mem­ber Robert Wat­son).

I saved some of the cor­res­pond­ing mails (to pub­lic mail­ing lists) in a mbox file, read the mess your­self if you want.

The bot­tom line is: Sev­eral com­mit­ters (even some which we could call high pro­file com­mit­ters) told me that they do not see a prob­lem in the use of the sy­sctl in­ter­face. They do not seem to want to tell it in pub­lic (nobody of them voiced their opin­ion in the thread, so do not ask me who those people are). I am not in­ter­ested in in­vest­ing more of my spare time into fight­ing wind­mills (it looks like this to me).

So, if someone is in­tersted in the code, r172631 has it. In the per­force re­pos­it­ory you can maybe find some sensors. I think most of it can still be used without much changes.

If someone tries it with a more re­cent FreeBSD, please drop me a note if it just ap­plies fine, or a patch (or an URL to it) if it needs some modi­fic­a­tions. Who knows, maybe in a fu­ture pro­ject it may be use­ful for me.

If there is enough in­terest by sev­eral people, I can even put up a wiki page where those people can co­ordin­ate, but that is most prob­ably all I am will­ing to in­vest fur­ther into this (at least in my un­paid time).

StumbleUponXINGBalatarinBox.netDiggGoogle GmailNetvouzPlurkSiteJotTypePad PostYahoo BookmarksVKSlashdotPocketHacker NewsDiigoBuddyMarksRedditLinkedInBibSonomyBufferEmailHatenaLiveJournalNewsVinePrintViadeoYahoo MailAIMBitty BrowserCare2 NewsEvernoteMail.RuPrintFriendlyWaneloYahoo MessengerYoolinkWebnewsStumpediaProtopage BookmarksOdnoklassnikiMendeleyInstapaperFarkCiteULikeBlinklistAOL MailTwitterGoogle+PinterestTumblrAmazon Wish ListBlogMarksDZoneDeliciousFlipboardFolkdJamespotMeneameMixiOknotiziePushaSvejoSymbaloo FeedsWhatsAppYouMobdiHITTWordPressRediff MyPageOutlook.comMySpaceDesign FloatBlogger PostApp.netDiary.RuKindle ItNUjijSegnaloTuentiWykopTwiddlaSina WeiboPinboardNetlogLineGoogle BookmarksDiasporaBookmarks.frBaiduFacebookGoogle ClassroomKakaoQzoneSMSTelegramRenrenKnownYummlyShare/​Save

12 thoughts on “FreeNAS & Sensors for FreeBSD”

  1. Thanks for your work, I hope your code to be merged back to FreeBSD.

    Not hav­ing sensors sup­port it is a ma­jor luck of func­tion­al­ity and I surely un­der­stand the reas­ons of the mi­gra­tion of freenas to linux. 

    I am an sysad­min and I want to know all the time what hap­pens to the in­ner of the serv­ers case’s.
    For this reason I have mi­grated sev­eral serv­ers from FreeBSD to Linux be­cause know­ing the op­er­a­tion states of sev­eral hard­ware pieces it is cru­cial and man­dat­ory for sysad­mins for the server avail­ab­il­ity and over­all se­cur­ity ar­chi­tec­ture.

  2. Pingback: FreeNAS, de BSD à Linux ? at FreeBSD-fr: Les nouvelles du géant en français
  3. “PHK com­plained loudly” : per­haps freebsd team should ex­clude this people : We are all wait­ing for “sensors” for a real long time. PHK cost us much more than just than “hey look at freebsd, they even lost freenas”. I’m us­ing FreeBSD for more than a dec­ade, not only I dis­covered today that the ma­jor thing miss­ing for mon­it­or­ing my cus­tom­ers had been voided by a sort of elit­ist com­miter, but also that the com­munity had lost one of the too main pro­jects..
    They’re is only one way to go for­ward, put back your code into the tree. In real life, noth­ing is “freezed”, even if your code was really “bad”, any­body can re­write the bad parts; that’s the way open­source works.…
    (Sorry for my poor eng­lish)

  4. Sensor sup­port is a “small” prob­lem for me: What I don’t un­der­stand is why the FreeBSD team re­fuse to in­clude the geom_​raid5 mod­ule used in FreeNAS !
    The ex­ist­ing geom_​vinum mod­ule in­cluded in FreeBSD 67 is too buggy for RAID 5: This is why FreeNAS uses an­other not-​official more stable geom mod­ule. But this mod­ule was never ac­cep­ted to be in­cluded in FreeBSD. Now the ori­ginal de­veloper of geom_​raid5 stop to main­tains it (dis­cour­aged), and it’s very hard to found someone to ad­apt it to FreeBSD 8.0.

    1. AFAIK geom_​vinum was up­dated for FreeBSD-​8. I can not re­mem­ber to have seen a post about geom_​raid5 on current@ or hackers@. Do you have a pointer to a dis­cus­sion re­gard­ing this on a pub­lic FreeBSD-​mailinglist? If this was not dis­cussed on a FreeBSD mailing­list, I sug­gest to start a dis­cus­sion there.

  5. 1. FreeNAS is not “mov­ing to Linux” – yes there’s a new pro­ject coreNAS that will. But I hope any­one who de­cides to change un­der­ly­ing plat­forms to use Linux is do­ing so for more reas­ons than just the sensor frame­work. Any­way coreNAS will be one of dozens of Linux NAS pro­jects. We use FreeNAS spe­cific­ally to lever­age FreeBSD stor­age tech­no­lo­gies (gjournal, iscsi, zfs) and have learned enough through cus­tom­iz­a­tion that we will just stick with FreeBSD if FreeNAS ever goes away (and right now it is not).

    2. PHK is not just “some elit­ist com­mit­ter”, sheesh. If PHK has con­cerns about im­pact on the ker­nel we should stop and listen – his vote gives him the abil­ity to make people stop and listen. He might be a bit Dan­ish in his dir­ect­ness but not every­one can be the dip­lo­mat à la RWat­son. PHK was given his vote for a reason so there’s no reason for ac­ri­mony. Whats more he is not the only per­son who has prob­lems with the OpenBSD sensor frame­work. It’s not 100% loved amongst OpenBSD devs and users (us­ing it for RAID is go­ing to be a prob­lem).

    3. It’s great that con­stantine and alex did this work. If it is truly “non-​disruptive” and can be sep­ar­ated from the ker­nel then why not just main­tain it as a port/​patch. Lots of ports of things that never make it into the ker­nel live on and do all kinds of stuff like build­ing cus­tom ker­nel mod­ules and user space tools for man­aging them­selves. If the sensors frame­work can’t do that then per­haps it is too dis­rupt­ive to in­clude by de­fault.

    I bet if you main­tain a patch on CURRENT tar­get­ting 9.0 and lots of people will try it.

    4. it might not seem like it but it’s still early days … :)

    1. It looks like the dis­cus­sion stops in the middle of resolv­ing some is­sues. BTW: the de­veloper in­ter­ested in get­ting this in the tree (Ulf) is also the geam_​vinum de­veloper.

      As it looks to me after read­ing the thread, that some im­port­ant work needs to be done be­fore it can go in.

      Maybe you want to con­tact lulf@ to know if there where some parts handled off-​list and what the status of it is.

  6. Just wanted to drop a line that couple of month ago I ad­ap­ted sensors code to head ver­sion of FreeBSD and I’ve been us­ing it since then. I am us­ing only it(4) driver though, and not do­ing any­thing fancy.
    As such I made couple of small im­prove­ments to it(4), in­clud­ing sup­port for 16-​bit fan speed coun­ters.
    Here’s my cur­rent diff against head:
    http://people.freebsd.org/~avg/sensors9.diff

  7. This is in­furi­at­ing, es­pe­cially now that the coretemp mod­ule re­ports it’s tem­per­at­ures in sy­sctl

    Has any­one taken it upon them­selves to get this merged into 8.2?

Leave a Reply

Your email address will not be published. Required fields are marked *