[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#639897: Please don't check /proc/mounts



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?

> 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;
}

Reply to: