9

Is it possible to get a reliable progress bar (or just a reliable information how long it will take) when doing updatedb?

student
  • 18,305

2 Answers2

7

This is not an efficient solution, but is not as bad as looping through everything twice.

Number of files processed by updatedb is equal to:

updatedb -v | wc -l

or roughly equal to:

find / -mount | wc -l

We cannot use these commands to get the number, because it would be looping twice.

But we can use the number of used inodes, which is approximately the same:

df -i | grep '/$' | awk '{print $3}'

Having this value, we can calculate how far we got while updatedb -v command is running:

count=$(df -i | grep '/$' | awk '{print $3}')

sudo updatedb -v | while read
do
    printf "%3d\r" $((100 * (++i) / count))
done

This is very inefficient, because printf is called for every line in the output of updatedb -v. Better if we printf for only some of the lines.

count=$(df -i | grep '/$' | awk '{print $3}')

sudo updatedb -v | while read
do
    if (( ++i % (count/20) == 0 )); then
        printf "%3d\r" $((100 * i / count))
    fi
done
musa
  • 1,018
  • 2
  • 10
  • 18
  • Interesting idea. But my df -i reports 0 in all columns for /. Maybe extracting the current database's file count from locate -S (or --statistics or other similar switch your locate implementation has) could also be used as an approximative file count. – manatwork Jul 18 '12 at 14:15
  • This solution worked for me, the percentage value seemed quite precise. – GeekInDisguise Jun 20 '18 at 00:45
  • updatedb does not have -v option anymore since 19.10, dunno if there are alternatives... – Klesun Mar 14 '21 at 15:20
5

No, there's no such option, as well it shouldn't have any.

If you need to measure that, you must first know how many files are present on your system, that means loop through everything twice, it can be slow

One evicent example is that if you extract kernel source code with file-roller, it's slower than doing the same thing with tar directly, because file-roller need to file out all files first(otherwise the progress bar might be incorrectly displayed), and you wait for a while before extraction process actually began.

daisy
  • 54,555
  • You are totally right. However, it would be possible to predict the time for the next run using a “smart guess”. For instance one could compute an exponentially weighted moving average from the past values, which basically assumes that the next run will take as long as the average of the last runs. This is of course not exact, but very cheap to compute since it doesn't loop over the file system. Given that neither the amount of files nor the load changes dramatically it will yield to very practical estimated values. – Marco Jan 12 '13 at 14:00