Everyday at some minutes after midnight the updatedb.findutils run to index some files. It's a program, which comes with Ubuntu. Now I wondered what this program does and found this.

root     12500 12491  0 00:10 ?        00:00:00 /bin/sh /usr/bin/updatedb.findutils
root     12533 12500  0 00:10 ?        00:00:00 su nobody -s /bin/sh -c /usr/bin/find / -ignore_readdir_race      \( -fstype NFS -o -fstype nfs -o -fstype nfs4 -o -fstype afs -o -fstype binfmt_misc -o -fstype proc -o -fstype smbfs -o -fstype autofs -o -fstype iso9660 -o -fstype ncpfs -o -fstype coda -o -fstype devpts -o -fstype ftpfs -o -fstype devfs -o -fstype mfs -o -fstype shfs -o -fstype sysfs -o -fstype cifs -o -fstype lustre_lite -o -fstype tmpfs -o -fstype usbfs -o -fstype udf -o -fstype ocfs2 -o      -type d -regex '\(^/tmp$\)\|\(^/usr/tmp$\)\|\(^/var/tmp$\)\|\(^/afs$\)\|\(^/amd$\)\|\(^/alex$\)\|\(^/var/spool$\)\|\(^/sfs$\)\|\(^/media$\)\|\(^/var/lib/schroot/mount$\)' \) -prune -o -print0

As you can see it defines a lot of filesystems it want's to (not) search for. Lot's of tmp spaces, exchangeable media locations, network locations and FSes are there but also one strange mountpoint which does not make any sense to me:


Where is this /alex used? And where would be a place to search for such information (except stackoverflow of course)?


That entry was added over 23 years ago by Kevin Dalley, and more detailed explanation was given in this bug report from 19 years ago:

I have had some trouble verifying the reason for excluding /alex, though I added it many years ago. /alex refers to the Alex file system. One reference to it is:


I'm not sure how common Alex file system is currently. It would probably be better to have the appropriate value in PRUNEFS rather than PRUNEPATHS. /afs may belong in the same category.

I'm leaving /alex and /afs in for the short term, but after I get a few more fixes in findutils, I will attack this problem.

That link is dead, but from the Wayback Machine:

The Alex file system provides users and applications transparent read access to files in anonymous FTP sites on the Internet. Today there are thousands of anonymous FTP sites with a total of a few millions of files and roughly a terabyte of data. The standard approach to accessing these files involves logging in to the remote machine. This means that an application can not access remote files like local files. This also means that users do not have any of their aliases or local tools available. Users who want to use an application on a remote file first have to manually make a local copy of the file. There is no mechanism for automatically updating this local copy when the remote file changes. The users must keep track of where they get their files from and check to see if there are updates, and then fetch these. In this approach many different users at the same site may have made copies of the same remote file each using up disk space for the same data.

Alex addresses the problems with the existing approach while remaining within the existing FTP protocol so that the large collection of currently available files can be used. To get reasonable performance long term file caching is used. Thus consistency is an issue. Traditional solutions to the cache consistency problem do not work in the Internet FTP domain:callbacks are not an option as the FTP protocol has no provisions for this and polling over the Internet is slow. Therefore, Alex relaxes file cache consistency semantics, on a per file basis, and uses special caching algorithms that take into account the properties of the files and of the network to allow a simple stateless file system to scale to the size of the Internet.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.