comment #5:

> If PRUNEPATHS contains /storage/backup, yet the db contains files from there, then there's something wrong.
> Please check what the effective find(1) command looks like.

Oops, please ignore this comment; it turns out that on my system, "locate" is actually "plocate". Sorry!

On my system, it's using around 4 GB of temporary files.

One thing I've noticed is that these files contain filenames from directories which are meant to be pruned: my PRUNEPATHS includes /storage/backup, but the /var/tmp/sortXXXXXXX files contain lots (all?) of the files in this hierarchy, which is both excessively space-consuming and time-consuming (updatedb took about 2 hours to run).  It may be that excluding files under PRUNEPATHS at file search time would make a significant difference to this issue.

Hello,

this is http://bugs.debian.org/654860 submitted by Attila Kinali:

------------------
Hi,

I am running locate/updatedb on my fileserver which contains a large amount of files (several milion). When running updatedb in such an enviroment, its subprocess sort will create a large amount (1.5GB in my case) of temporary data in /var/tmp. If /var/tmp is on a rather small partition, this will cause the partition to be completely filled up.

The solution is to tell sort to use gzip on its temporary data, which results in a decrease of temp data size by a factor of 10. The performance impact on updatedb is negligible (less than 1%).

                        Attila Kinali
------------------

Attila suggests to simply use "sort --compress-program=gzip ...", I guess a clean patch would need to doublecheck at ./configure whether sort actually supports this option.