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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-devel-list
