On Thu, Sep 1, 2011 at 09:54, Julian Andres Klode <j...@debian.org> wrote: > (a) APT sometimes needs to get the partition table and looks for /etc/mtab > and /proc/mount, the latter missing the "s" at the end. This should > be fixed -- and once it is, APT would read the file itself as well > in addition to the indirect use we currently have.
Ah now I see. >> > Furthermore, I cannot reproduce this at all. What might be helpful >> >> Oh really? I had no problem seeing this on our squeeze servers and on >> my sid workstation, and I don't think I did anything unusual. > Mount points somewhere on /var, /var/cache, /var/cache/apt/, > /var/cache/apt/archives? Not 64-bit? just a tmpfs on /var/cache/pbuilder/build >> > would be a backtrace for the open call, so we know why it >> > happens (ltrace -S e.g. traces both library and system calls, and >> > with -C you get readable C++ names). >> >> I've run ltrace with -S -C options on "apt-get autoremove" on my sid >> workstation, and you can find the (big) output at [1]. >> >> [1] http://people.debian.org/~morph/639897_ltrace_S_C.out.bz2 > This tells me that statvfs64() in libc6 reads it, and > reading the eglibc code confirms this, it's read in: > sysdeps/unix/sysv/linux/internal_statvfs.c Oh yes, I can replicate this behavior with the attached tiny C code: if I run it on our production machines I got: # time ./a.out real 5m44.859s user 0m0.468s sys 5m44.054s and in fact we have: # wc -l /proc/mounts 235464 /proc/mounts I'm adding Aurelien (libc maintainer) in the loop: hi Aurelien! we're facing a slowliness problem on systems with a lot of mounts (ok, it's kinda rare situation) due to statvfs64() reading the whole /proc/mounts . Can you suggest something to alleviate this issue? > It needs to do this to get the mount options to report them > back. We only want the free space, though. > > One option we have (at least on Linux) is to use statfs() > instead, as statfs() reports only a subset of statvfs() > information, and does not need to read /proc/mounts. At > least LSB has deprecated this, though, and recommends > the POSIX statvfs() interface we currently use. Well, I don't know if it would be a solution: if the other function is deprecated and you should use statvfs64() I don't think you have actually a choice. Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi
#include <sys/statvfs.h> int main(int argc, const char *argv[]) { struct statvfs64 Buf; statvfs64("/var",&Buf); return 0; }