Recent blog entries for hasienda

Yesterday I took the time to look into an annoyance, that threaded me for some weeks now: When I tried to rsync a local Mercurial copy of an SVN repository (managed by hgsubversion), it failed suddenly with 'No space left on device'.

No, what? I'm monitoring my drives quite loosely, but a look at actual free disc space confirmed: less than 70 % used. So what?

Turned out the sheer amount of small files used especially for Mercurial meta-data had eaten up all available inodes, what had gone unnoticed up to that point. The repository is locally stored inside a 10G partition, but it's copied to another place only 2,5G big. While both are ext3 file systems, not only the fs size significantly affected the total number of inodes, but the double inode size of 256 Byte for the smaller partition (newer installation) compared to 128 on the older, bigger partition did a great deal on shortening available inodes as well.

The diagnosis was followed by an - initially rather desperate - search to find and understand possible solutions. I wouldn't buy some early results, but it become obvious be few more hours: There's no such thing like file system tuning for inodes. Not that technically it can't be done, more likely there has been not much demand to write code for bringing such a feature i.e. into tune2fs. You're forced to rebuild your fs with more sensible settings for the fs management internals to better fit it to your usage.

Good thing, I had plenty of room in my LVM managed remote system, so build another 2,5G part and experimenting with different bytes/inode ratios ('-i' switch for mkfs.ext3) was a matter of minutes. After finding a sensible value I copied the whole fs over with 'cp -a', and after working with the copy on the new partition a bit I copied the whole thing back with dd_rescue (favored over dd for a nicer progress indicator), every time with the copied source as fallback option.

All in all a great and quite painless lesson on fs internals, that have been rather subtle to me so far, despite doing GNU/Linux system setups for 10+ years now.

25 Feb 2011 (updated 26 Feb 2011 at 01:27 UTC) »

Tonight I'm experimenting with 2D matrix code on Debian GNU/Linux. I found, grabbed, built and installed pyDataMatrixScanner [1] and it's dependencies. Getting the live image from my good old PCVC830 (ToUCam II) USB webcam displayed in a window was a matter of some more minutes (reading the README).

Now it get's interesting. Appears, that there is no python-virtkey package in Debian, that would be required for some advanced functionality. Ubuntu has it. When I queried the web about it, I got several hints on a bug [2] regarding packaging of this package resolved in Sept-2010. The very last comment of this bug report made me smile a lot:

> Thank to all developers for fix it...I'm Spanish and I'm 16...When I'm more old...I want to be like you.
> Thanks and regars!

I fixed this bug, and I am 14! ...


Edit1,2: Dependencies for Ubuntu Maverick's python-virtkey can't be satisfied by Debian Squeeze. I ended up compiling and installing my own python-virtkey from Maverick's virtkey 0.60.0-0ubuntu2 source package. Note also, that the needed pydmtx Python wrapper for libdmtx is hidden in libdmtx-dev. You need to unpack source files in /usr/share/doc/libdmtx-dev/examples/python/ and do a python ./setup install manually (as root).

Apt-proxy is no longer available in Debian 6.0, so finding a successor has become a mandatory task when upgrading my home server today.

I chose apt-cacher-ng after some research on the web. Looks like a promizing quality project, and migration was quite easy with the help of a complete "Howto replace APT-Proxy with APT-cacher-ng" [1]. And I learned, that now I have an APT proxy for the first time, while apt-proxy wasn't a real one - just by it's (misleading) name.

After a short and smoth setup and data migration again I'm glad to have been pushed one step ahead. This is the Debian way, not exactly easy and compfortable at all times, but certainly worth the hassle. Debian devs, thank you!


New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!