Re: prunefs/paths on AIX

[AIXperts Consultancy ltd.]

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