Please test: mlocate

[Miloslav Trmac]

Hello,
http://people.redhat.com/mitr/mlocate/i386/mlocate-0.10-0.testing.1.i386.rpm
contains mlocate, a new locate implementation.  The 'm' stands for "merging":
updatedb reuses the existing database to avoid rereading most of the file
system, which makes updatedb faster and does not trash the system caches as
much (some data are at end of this message).

The locate(1) utility is intended to be completely compatible to slocate.
It also attempts to be compatible to GNU locate, when it does not conflict
with slocate compatibility.


mlocate seems to work well so far, but it has been tested only on ext3.
Because mlocate is sensitive to filesystem timestamp semantics,
testing with rarely used filesystems or uncommon automounting setups
would be most valuable.  Any other testing and comments are of course
welcome as well.

The package is prepared to install alongside slocate (it actually requires
slocate because I didn't want to allocate a GID for mlocate yet):
configure it at /etc/mupdatedb.conf and then just use (mlocate) instead
of (locate).

This is the first public release, so be please be careful: mlocate
certainly has a few bugs and it has not been independently audited 
for security issues.


Now, the promised numbers: each time, a computer was booted into
single-user mode; after one updatedb run data was collected using
(slabtop) and (free).  The measurement method is admittedly crude,
but I think the numbers represent reality quite well.

Run:		real	user	system	dentry	inode	buffers	cached
slocate:	1m32.84	0.704	2.045	134337	170778	85972	 8268
mlocate, 1st:	1m11.65	0.214	0.908	 17766	 15642	78452	21340
mlocate, 2nd:	  37.64	0.105	0.289	 17776   15639  33996   21336

real, user, system: as reported by (time)
dentry, inode: number of active objects in dentry_cache and ext3_inode_cache,
	as reported by (slabtop)
buffers, cached: size of disk buffers and page cache, as reported by (free).

mlocate has two rows because the first run needs to rescan the whole
file system, while the subsequent runs can reuse most of the original
database.
	Mirek