Good afternoon,
> Is the locatedb so huge, or are there some pseudo paths like /sys or
> (undetected?) recursive mounts involved?
Apologies, prunepaths does work, some numbers below. This system has
about 3 million files on it:
locatedb = 73MB
sort files at peak = ~600MB
If I exclude a filesystem with a large number of files, I get:
locatedb = 3MB
sort files at peak = ~100MB
As far as I can tell, it uses /usr/bin/sort (AIX sort) but for some
reason GNU find:
# grep sort /usr/bin/updatedb
sort="/usr/bin/sort"
sort="/usr/bin/sort -z"
sort="/usr/bin/sort"
[...]
# grep find /usr/bin/updatedb
[...]
: ${find:=${BINDIR}/find}
[...]
# grep BINDIR /usr/bin/updatedb
if test -n "$BINDIR" ; then
: BINDIR already set, do nothing
: ${BINDIR=/opt/freeware/bin}
: ${find:=${BINDIR}/find}
I did try running it using GNU sort with default flags, which still used a
substantial amount of temporary space.
> Second, what `sort` implementation is that?
> If it's GNU sort from coreutils, then you can tell it e.g via the environment
> variable TMPDIR where to write larger temporary files than in /tmp.
/tmp or /var is usually where the most space is available. But not necessarily
600MB on all systems.
> What is the resulting `find` command?
+ /opt/freeware/bin/find / ( -fstype 9P -o -fstype NFS -o -fstype afs -o
-fstype autofs -o -fstype cifs -o -fstype coda -o -fstype devfs -o -fstype
devpts -o -fstype ftpfs -o -fstype iso9660 -o -fstype mfs -o -fstype ncpfs -o
-fstype nfs -o -fstype nfs4 -o -fstype proc -o -fstype shfs -o -fstype smbfs -o
-fstype sysfs -o -type d -regex \(^/ora1$\) ) -prune -o -print
Running that find command yields 241MB of output.
The full command run to find and sort is:
+ /opt/freeware/bin/find / ( -fstype 9P -o -fstype NFS -o -fstype afs -o
-fstype autofs -o -fstype cifs -o -fstype coda -o -fstype devfs -o -fstype
devpts -o -fstype ftpfs -o -fstype iso9660 -o -fstype mfs -o -fstype ncpfs -o
-fstype nfs -o -fstype nfs4 -o -fstype proc -o -fstype shfs -o -fstype smbfs -o
-fstype sysfs -o -type d -regex \(^/ora1$\) ) -prune -o -print
+ /usr/bin/sort -f
It's getting a bit more mysteries though, as the growth caused on the system I
am looking at is caused purely by building of /var/locatedb.n but in the past
when we have had alerts for /tmp filling up, it has been down to /tmp/stm*
files which come from IBM's sort. I will have to wait for another alert caused
by stm-files to find out what the difference is.
Regards,
Henrik Morsing
