v4l sup­port in the lin­ux­u­la­tor MFCed to 8‑stable

I merged the v4l trans­la­tion lay­er into the lin­ux­u­la­tor of 8‑stable. As in ‑cur­rent, this just means that lin­ux apps (like Skype) can now use FreeB­SD native devices which con­form to the v4l ABI. The port multimedia/webcamd pro­vides access to some web­cams (or DVB hard­ware) via the v4l ABI.

Peo­ple which want to test the lin­ux­u­la­tor part should first make sure a native FreeB­SD appli­ca­tion has no prob­lem access­ing the device.

The rea­son why this blog was not acces­si­ble to some people

I got noti­fied that my blog was not acces­si­ble for a while. Seems that at least recent fire­fox ver­sions some­how changed their behav­ior in what is send in the HTTP-header. This caused an Apache Redi­rect­Match rule to trig­ger, which denies access to some parts of the blog for some users.

The WP-login, WP-dashboard, and logged-in users where not affect­ed by this, so if you have some cus­tom rules which deny access to your blog, make sure you make a test of your blog when logged-out.

Peri­od­ic scrub­bing of ZFS pools

I noticed that we do not have some auto­mat­ic way of scrub­bing a ZFS pool peri­od­i­cal­ly. A quick poll on fs@ revealed, that there is inter­est in some­thing like this. So I took a lit­tle bit of time to write a peri­od­ic dai­ly script which checks if the last scrub is X days ago and scrubs a pool accord­ing­ly. The script has options to scrub all pools, or just a spe­cif­ic sub­set. It also allows to spec­i­fy a time-interval between scrubs for each pool with dif­fer­ent lev­els of fall-back (if no pool-specific inter­val is set, the default inter­val is used, which is set to 30 days if no oth­er default inter­val is specified).

The dis­cus­sion about this is hap­pen­ing over at fs@, so go there and have a look for the CFT (with a link to the WIP of the script) and the dis­cus­sion if you are interested.

So far there are some minor details to sort out (and a lit­tle bit of doc­u­men­ta­tion to write) before I can com­mit it… prob­a­bly next week.

Under­stand­ing latency

Bren­dan Gregg of Sun Ora­cle fame made a good expla­na­tion how to visu­al­ize laten­cy to get a bet­ter under­stand­ing of what is going on (and as such about how to solve bot­tle­necks). I have seen all this already in var­i­ous posts in his blog and in the Ana­lyt­ics pack­age in an Open­Stor­age pre­sen­ta­tion, but the ACM arti­cle sum­ma­rizes it very good.

Unfor­tu­nate­ly Ana­lyt­ics is AFAIK not avail­able in Open­So­laris, so we can not go out and adapt it for FreeB­SD (which would prob­a­bly require to port/implement some addi­tion­al dtrace stuff/probes). I am sure some­thing like this would be very inter­est­ing to all those com­pa­nies which use FreeB­SD in an appli­ance (regard­less if it is a stor­age appli­ance like NetApp, or a net­work appli­ance like a Cisco/Juniper router, or any­thing else which has to per­form good).

LAME updat­ed in the FreeB­SD ports collection

After all the big-impact com­mits (Gnome/gettext/KDE/X11/…) have set­tled now, I took the time to update audio/lame (I iden­ti­fied more than 100 ports with an (implic­it) depen­den­cy on lame, 45 of them need­ed a portre­vi­sion bump; if I forgot/overlooked some, bump the revi­sion your­self or noti­fy me please). That is the first update of my ports where miwi@ did not beat me in com­mit­ting an update since a year (he has implic­it approval to do any­thing he wants with my ports).

I can be hap­py that he is/was this fast (and that we have such a pro­duc­tive and effi­cient com­mit­ter), or I can be sad that I do not have the time any­more to be faster than I am with such things… or both. Hmmm… I think I will go the hap­py way. 😉