Package: mlocate Version: 0.19-1 Severity: normal If you strace updatedb.mlocate, it'll look like this:
stat64("/etc/mtab", {st_mode=S_IFREG|0644, st_size=684, ...}) = 0
lstat64("debian", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
chdir("debian") = 0
lstat64(".", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/etc/mtab", {st_mode=S_IFREG|0644, st_size=684, ...}) = 0
lstat64("po", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
fchdir(14) = 0
stat64("/etc/mtab", {st_mode=S_IFREG|0644, st_size=684, ...}) = 0
lstat64("init.d", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/etc/mtab", {st_mode=S_IFREG|0644, st_size=684, ...}) = 0
lstat64("parted_names", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/etc/mtab", {st_mode=S_IFREG|0644, st_size=684, ...}) = 0
I imagine that linux caches most of the stat calls, but 2x system call
overhead just to stat /etc/mtab in between each directory scanned cannot be
good for performance. It is caused, I think, by glibc checking that
its cached /etc/mtab is up-to-date each time a *mntent() function is
called.
If I set PRUNE_BIND_MOUNTS="no" in updatedb.conf, the mtab stats go
away. There is a measurable speed change, seems to be around 10 seconds
based on the following best run times out of three:
yes: 2.27user 8.96system 7:37.63elapsed 2%CPU
no: 2.04user 8.76system 7:26.19elapsed 2%CPU
So perhaps it would be worth caching the mntent values in updatedb?
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages mlocate depends on:
ii adduser 3.107 add and remove users and groups
ii libc6 2.7-10 GNU C Library: Shared libraries
mlocate recommends no packages.
-- no debconf information
--
see shy jo
signature.asc
Description: Digital signature
