As pre­vi­ously reported, I tried the update to Android 3.2 on my Tab and was not happy about the new EMail app. At the week­end I had a lit­tle bit of time, so I tried to get the Email.apk from Android 3.1 into Android 3.2.

Long story short, I failed.

Tita­ni­um­Backup PRO was restor­ing or hours (the option to migrate from a dif­fer­ent ROM ver­sion was enabled) until I killed the app, and it did not get any­where (I just emailed their sup­port if I did some­thing com­pletely stu­pid, or of this is a bug in TB). And a copy by hand into /system/apps did not work (app fails to start).

Ideas welcome.

A while ago I com­mit­ted the lin­ux­u­la­tor D-Trace probes I talked about ear­lier. I waited a lit­tle bit for this announce­ment to make sure I have not bro­ken any­thing. Nobody com­plained so far, so I assume noth­ing obvi­ously bad crept in.

The >500 probes I com­mit­ted do not cover the entire lin­ux­u­la­tor, but are a good start. Adding new ones is straight for­ward, if some­one is inter­ested in a junior–ker­nel–hacker task, this would be one. Just ask me (or ask on emu­la­tion@), and I can guide you through it.

I have the habit to chmod with the rel­a­tive nota­tion (e.g. g+w or a+r or go-w or sim­i­lar) instead of the absolute one (e.g. 0640 or u=rw,g=r,o=). Recently I had to chmod a lot of files. As usual I was using the rel­a­tive nota­tion. With a lot of files, this took a lot of time. Time was not really an issue, so I did not stop it to restart with a bet­ter per­form­ing com­mand (e.g. find /path –type f –print0 | xargs –0 chmod 0644; find /path –type d –print0 | xargs –0 chmod 0755), but I thought a lit­tle tips&tricks post­ing may be in order, as not every­one knows the difference.

The rel­a­tive notation

When you spec­ify g+w, it means to remove the write access for the group, but keep every­thing else like it is. Nat­u­rally this means that chmod first has to lookup the cur­rent access rights. So for each async write request, there has to be a read-request first.

The absolute notation

The absolute nota­tion is what most peo­ple are used to (at least the numeric one). It does not need to read the access rights before chang­ing them, so there is less I/O to be done to get what you want. The draw­back is that it is not so nice for recur­sive changes. You do not want to have the x-bit for data files, but you need it for direc­to­ries. If you only have a tree with data files where you want to have an uni­form access, the exam­ple above via find is prob­a­bly faster (for sure if the direc­tory meta-data is still in RAM).

If you have a mix of bina­ries and data, it is a lit­tle bit more tricky to come up with a way which is faster. If the data has a name-pattern, you could use it in the find.

And if you have a non-uniform access for the group bits and want to make sure the owner has write access to every­thing, it may be faster to use the rel­a­tive nota­tion than to find a replace­ment command-sequence with the absolute notation.

My wife decided that we need a cam­corder. As I am a good hus­band, I do not com­plain (she pays ).

There was an offer in a super mar­ket nearby. Not as low as you can find in the inter­net, but if there is a prob­lem, it is much more easy to com­plain. For some­thing like this, I/we pre­fer this and am-are OK to spend a lit­tle bit more money for this con­ve­nience.

This cam­corder is record­ing to SDHC cards. Such cards have a speed rat­ing, and you need to take some min–speed one, to be able to record videos with a cam­corder. Unfor­tu­nately Sam­sung does not list the speed rat­ing some­where. I searched on the Sam­sung site in the spec­i­fi­ca­tions and in the FAQ. Noth­ing. After a lit­tle bit of googling I at least found a review where the record­ing time for spe­cific card-sizes where listed.

So I took the card-size in MB, divided it by the record­ing time in sec­onds, and got the data trans­fer rate per sec­ond for the spec­i­fied res­o­lu­tions. The 1080i res­o­lu­tion has the high­est trans­fer rate and as such it is the most inter­est­ing one to decide what kind of card one needs.

The high­est trans­fer rate seems to be less than 2.2 MB/s, so a class 4 SDHC card should be enough.

I noticed that we do not have some auto­matic way of scrub­bing a ZFS pool peri­od­i­cally. 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­odic daily script which checks if the last scrub is X days ago and scrubs a pool accord­ingly. The script has options to scrub all pools, or just a spe­cific sub­set. It also allows to spec­ify a time–inter­val 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 other 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.