On Tue, 09.09.08 18:20, Colin Guthrie ([EMAIL PROTECTED]) wrote: > > The cache is completely redundant btw. You can just delete it and > > it will be recreated from scratch on-demand. > > > > The cache file is stored in ~/.cache (the XDG cache dir). It has the > > build host string (to avoid packing/endianess issues) and a machine id > > in the name (because this is per-machine data on NFS $HOME). The > > machine id is the D-Bus UUID (if exists) or otherwise the host name. > > Cool thanks for the info. > > FWIW, I presume the tdb is OK on NFS? For example, sqlite seems to have > issues on NFS shares due to locking (tho' e.g. Firefox seems to cope OK, > other apps have had big problems).
The way it uses POSIX locks should generally be NFS safe. Of course, in some situations with misconfigured or ancient NFS servers they won't work properly and this will not necessarily be detected. However, I tried to make sure that if any db operation fails and this is detected we will just ignore the cache and fall back to non-caching mode. Also, since the cache is per-machine the most problematic issue which is locking across the network is not triggered. Also all entries are validated before they are used, and if they turn out to be out-of-date they will be ignored. All in all, I believe things are pretty robust and the worst that can happen on an NFS share with broken locking is that we will bypass the cache, but that appears good enough to me. That said I of course didn't test against any broken NFS implementation, and guessing which errors might happen and working around them is always a game of luck, so YMMV. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 _______________________________________________ libcanberra-discuss mailing list [email protected] https://tango.0pointer.de/mailman/listinfo/libcanberra-discuss
