On Tue, Mar 20, 2007 at 12:50:26AM +0100, Miloslav Trmac wrote:
Axel Thimm napsal(a):
On Mon, Mar 19, 2007 at 11:51:19PM +0100, Miloslav Trmac wrote:
Hello, Axel Thimm napsal(a):
- locate(1)'s default database is not just /var/lib/mlocate/mlocate.db; mlocate also checks each mounted filesystem for a .mlocate/mlocate.db file, owned by root or the invoking user, and not writable by anyone but the owner. Such files are automatically added to the database path.
locate should also include .mlocate/mlocate.db a previous updatedb has found and skipped. E.g. if updatedb detects a .mlocate/mlocate.db in a folder in its path it skips it and registers it for locate to use.
I can't think of a reason why they would be necessary.
Consider for example a single volume nfs server exporting /home. So you want to have updatedb create a subdirectory-local db in /home, so it can be used on remote clients.
But on the client, where locate runs, /home/foo would be a separate filesystem.
Yes, but updatedb (and locate) runs also on the server.
As for updatedb,
And instead of having to configure it in /etc/sysconfig it is easier to keep the metainformation of about where such .mlocate/mlocate.db should be maintained in the fs itself simply by creating the folder .mlocate.
wouldn't it be even more practical to support FS_DB_GLOB=/srv/home/* in /etc/sysconfig/mlocate ?
It's better not to have any knowledge under /etc of where special .mlocate/mlocate.db are injected on the (local) filesystem. Consider the (local) volume in question to be mounted from a SAN device, maybe even in a cluster active/passive setup. Or consider moving a data disk from one system to another.
It's better to try and keep the metainformation non-global (e.g. out of /etc) and self-describing, so it is rather transparent for the admin. Otherwise he needs to cater for any change of host <-> storage mapping in mlocate as well.