Bug#639897: Please don't check /proc/mounts
On Fri, Sep 02, 2011 at 11:33:33AM +0200, Sandro Tosi wrote:
> On Thu, Sep 1, 2011 at 09:54, Julian Andres Klode <jak@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?
>
As always, when the libc doesn't have the information from a kernel
syscall, it needs to get it another way, and it often ends up using
/proc or /sys as the source of information. In some cases it can't take
huge amount of time, but the problem is not that the libc doesn't parse
the pseudo file inefficiently, just that the kernel has to generate
insane amount of useless data.
In your case of statvfs(), the problem has been solved a bit more than
one year ago, by exporting the missing data directly through the
syscall. For that you need a libc >= 2.13 and a kernel >= 2.6.36. I
guess in your case you are using Squeeze, which doesn't meet these
requirements.
The libc patch is trivial to backport, having it in squeeze is mostly
about convincing the release managers that it's useful and safe. On the
kernel side, it seems a bit more complicated, as the change has been
followed by a lot of small bug fixes.
Cheers,
Aurelien
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
Reply to: