Re: prunefs/paths on AIX

"AIXperts Consultancy ltd." <[email protected]>
Newsgroups gmane.comp.gnu.findutils.bugs
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.