Contributed by Paul 'WEiRD' de Weerd on from the cache-this dept.
I spent the first day and a half chasing an issue that many people have been experiencing: the first X start after an install or upgrade from a snapshot was slow. The direct cause of this is well-known: it's the fontconfig library (used by all applications that do font rendering) that re-builds its font cache (~/.cache/fontconfig/) because of newly installed fonts.
Except that normally, OpenBSD X sets ship a pre-computed, system-wide cache (/var/cache/fontconfig/) that should avoid this. So what is the problem ?
I found two reasons for this. The first one was a bug in the fontconfig library, introduced with the more recent re-work of the caching code, which would incorrectly compare the nano-seconds part of the time stamp of the installed fonts with the one from the cache (it was comparing it against the integral seconds part instead). This was not enough to fix the original issue, but it gave a clue…
In fact the problem comes from the fact that the fonts extracted from the tarballs get their last modification time stamps restored only with one second precision, since the nanoseconds parts of the mtime field is not stored in the USTAR file format used by OpenBSD distributions sets. But the pre-computed cache uses the full time stamp, including nanoseconds. So after extracting the sets, the cache data doesn't match the actual installed fonts and fontconfig decides to re-build it.
My suggestion to just stop shipping a pre-computed cache and to recompute it as part of the rc.firsttime script that is run on each install/upgrade was rejected by the hack room as too expensive for slower machines. Fixing OpenBSD's pax(1)/tar(1) command to store the extended nanoseconds field in the archives (there are extensions to the USTAR file format for this, they are just not supported) was also considered as too expensive, although some people agreed that OpenBSD should add support for this extension at some point…
So that left us with the solution of get the pre-computed cache to be valid with only one second resolution, ie force the nano-seconds part of the last modification time stamp in the installed fonts to be zero. This solution was suggested remotely by millert@
For this guenther@ and espie@ perl skills helped to stick this in a perl one liner. Curious readers will find it in xenocara/fonts/alias/Makefile.bsd. Et voila, OpenBSD's fonts set now match after extraction what was there when the contents of /var/cache/fontconfig was computed and fontconfig is happy and won't trigger a rebuild.
After this, I got back to my original project of working a bit more on xenodm(1), the stripped down X Display Manager that replaced xdm(1) in Xenocara. I've fixed a couple of bugs cleaned a few more unused code and got a better view on what can be done to eventually better protect it with privilege separation and pledge. But this is not finished yet, so it leaves things to do for a next hackathon.
I've enjoyed Ljubljana for the third time, it's nice food, graffiti and all the interactions with other OpenBSD developers, including some new heads.
Thanks to Mitja and all people who made g2k18 possible.
Many thanks to Matthieu for his report and the work on X in general!
(Comments are closed)