I noticed that we do not have some automatic way of scrubbing a ZFS pool periodically. A quick poll on fs@ revealed, that there is interest in something like this. So I took a little bit of time to write a periodic daily script which checks if the last scrub is X days ago and scrubs a pool accordingly. The script has options to scrub all pools, or just a specific subset. It also allows to specify a time–interval between scrubs for each pool with different levels of fall-back (if no pool-specific interval is set, the default interval is used, which is set to 30 days if no other default interval is specified).
The discussion about this is happening over at fs@, so go there and have a look for the CFT (with a link to the WIP of the script) and the discussion if you are interested.
So far there are some minor details to sort out (and a little bit of documentation to write) before I can commit it… probably next week.
I experimented a little bit with the order of directories to backup in tarsnap.
Currently I use the following sorting algorithm:
- least frequently changed directory-trees first
Every change – even in meta-data – will affect the following data, as tarsnap is doing the de-duplication in fixed-width blocks (AFAIR 64k).
- for those directory-trees which change with the same frequency: list the bigger ones first
Implicitly I assume that the smaller ones are much smaller than the bigger ones so that the smaller part which will be backed up will not be noticed because of the bigger change. For my use cases of tarsnap this is true.
- if changes in a directory-tree are much much bigger than anything else, but the directory-tree has a medium change-frequency, put it even before less-frequently changing stuff
I do not want that a small change triggers a big backup, but a big backup can contain the remaining small part.
- if you backup home directories (even root’s one) and they do not contain much data, put them before directory-trees which change a lot daily
I do not want that a login triggers the transfer of data in other directory-trees which have not changed.
Unfortunately you can not chose…
So, I am now on the sofa, covered a lot (a flu, I even have no voice anymore; before I left work a female coworker told that her husband would probably be happy if this would happen to her… 😀 ) and medication and water are not far away on the table.
The good thing with the current technology is, that you can still be a little bit productive (depending on the illness).
As you can read this, it means I have my netbook with me, so that I can take care about some simple things.
I am in the process of preparing the import of code which makes v4l devices usable in the linuxulator. Basically this means you can use your webcam in skype (tested by the submitter of the patch on amd64).
This is not a “apply patch and commit” thing, because the original videodev.h (with some modifications) is used. I was seeking the OK from core@ for this. As there is no license in the header, and the original author (Alan Cox, the linux one, not our FreeBSD one) gave permissions to use it, core@ is OK with the import.
I intent to do a vendor import of the linux header (prepared today, together with some readme which explains where it comes from and some stuff to show that we are on the safe side regarding legal stuff), and then I want to copy this over to the linuxulator as linux_videodev.h and commit the patch (probably a little bit modified in a few places). My plan is to commit it this week. People which already want to play around with it now can have a look at the emulation mailinglist, a link to the patch is posted there.
With the header being in a vendor branch, interested people could then start to submit new BSD licensed drivers or modify existing drivers which make use of the v4l interface, but I let the import of the header into the FreeBSD include directory up to the person which wants to commit the first native FreeBSD-v4l support.
When such native FreeBSD-v4l support is committed, the linuxulator code needs to be revised.