# as per upstream... tag 478437 wontfix thanks * Olivier Berger [Fri, 21 Mar 2008 20:32:29 +0100]:
> It seems to me updatedb.mlocate is issueing a lot too many calls to > stat64() on /etc/mtab, as seen stracing the process execution. Hello. I forwarded this bug report to upstream and here's their response: -8<- Thanks for your report. This happens in `src/updatedb.c:is_bind_mount()`. Some bind mounts can not be identified by comparing `st_dev`. The only way to identify them is to check the path is not one of known bind mount paths, and to make sure the list of known bind mount paths is current. Keeping the list current is important because `updatedb` can run for several minutes and it could unnecessarily overload the network if it did not exclude a mount point that had been mounted after updatedb was started. Refreshing the list only once per second (or other small interval) does not help because checking the time interval would require as many system calls as checking whether `/etc/mtab` has changed. Refreshing the list only once per e.g. 100 directories scanned would decrease the number of system calls, but it would make `updatedb` unreliable: if one directory from the "batch" of 100 directories were an unavailable NFS mount, the time to scan the "batch" could be many minutes, and bind mounts mounted in the meantime over other directories in the batch would not be noticed. The `mlocate` implementation does focus on performance, but correctness always comes first. The overhead measured in Debian #478437] is less than 3% of real time, which I consider quite acceptable. ->8- The URL for the upstream bug report is: https://fedorahosted.org/mlocate/ticket/1 -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Testing can show the presence of bugs, but not their absence. -- Dijkstra -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
