Apple has released another update for Mac OS X Leopard yesterday. As usual it fixes a lot of security problems and bugs.
Unfortunately it also breaks the development environment, and not for the first time. The update included new shared libraries e.g. version 0.11.8 of pixman. The related libtool archives however were not updated. As a result linking with one of the affected libraries fails because libtool tries to use an old version which no longer exists. Even after installing the latest version of Xcode (3.1.1) the problem remains.
Apple really needs to come up with a way to keep the development environment in sync with security updates.
After my LDAP server stopped working I had to re-configure my Mac to use NIS which caused me a lot of problems under Mac OS X in the past. But it seems that Apple actually fixed NIS support in Mac OS X Leopard. During the two days I used NIS as the directory service on my Mac I didn’t experience any login failures or NFS problems. AutoFS, the new automounter, even picked up the hierarchical Solaris-style automounter maps that my NIS server provides.
Since yesterday evening my Mac is using LDAP again after I managed to fix the LDAP server. But it is good to know that I can use NIS as backup solution.
A few weeks ago I posted about NetBSD’s new journaling technology WAPBL. I received a lot of questions concerning the benchmark results that I published. People were especially interested in a comparison with FFS using soft dependences. I hadn’t used this mode in my original benchmark because my personal experiences with soft dependences weren’t very positive.
I decided nevertheless to repeat the benchmark using the default mode (no mount options), asynchronous mode (-o async), soft dependences (-o softdep) and WAPBL (-o log). I also changed the benchmark itself:
- Before each benchmark run the file system is initialized using a block size of 16KB and a fragment size of 2KB. As no space is reserved at the end of partition WAPBL has to use an in file system journal.
- During the tar phase the benchmark extracts the NetBSD 4.0 source tar archives ten times into seperate directories. The file set is now considerably larger than the main memory of the test machine. The source tar archives were fetched from a memory file system before this phase to make sure that the buffer cache is pre-populated.
- During the rm phase the benchmark removes the 10 directories it has created previously.
- Both phases are finished by running the sync command and unmounting the file system to make sure that all buffers have been written to disk.
- The times quoted in the table below include the time it took to unmount the file system. The values were calculated by taking the average of four runs of the benchmark. All values are denoted in minutes:seconds.
Let’s have a look at the results:
- The synchronous mode (synchronous metadata writes) provides the worst performance, the asynchronous mode the best. Anything else would have been a big suprise.
- Soft dependences provide much better performance than the synchronous mode. But they can be considerably slower than the asynchronous mode depending on the work load.
- WAPBL is slower than the asynchronous mode but not by much. It is always faster than soft dependences.
Considering these benchmark results and the fact that only WAPBL can recover from a system crash without an expensive file system check it is the clear winner, at least in my humble opinion.