Greetings,

mlocate updatedb manifests some interesting behavior when used with
autofs5 and direct maps. We have some fairly deep automount structures
here, where there can be several subdirectories between the direct
mount point and the first actual NFS mount. Direct maps deal with
this, but the system thinks that everything above the first actual NFS
directory is local disk. 

For example, say I have a direct map on /prj with some entries like so:

/prj/sub1/sub2/sub3/foo -rw,noquota,intr            somefiler:/path/to/foo
/prj/sub10/sub11/sub12/bar -rw,noquota,intr         somefiler:/path/to/bar
/prj/sub20/sub21/sub22/baz -rw,noquota,intr         somefiler:/path/to/baz
...

If you cd to /prj/sub1/sub2/sub3, df will report that the underlying
filesystem is local disk mounted on /. If I run
/etc/cron.daily/mlocate.cron it will descend this hierarchy (since it
appears to be local disk), mounting the NFS exports at the bottom. It
does not index the contents of the mounts but it generates a lot of
autmount traffic 

Having nfs in the PRUNEFS in /etc/updatedb.conf does not prevent
this. The only way to stop it reliably is to put the mount points into
PRUNEPATHS.

This is a new problem for us. In RHEL3/4, we used a program map to
mount these project hierarchies: the subdirectories weren't ghosted so
I assume the mount looked empty to updatedb and so was ignored.

I'm not certain this is a bug, but it sure is unexpected (to me at
least) and it could make for a rude wakeup to anyone deploying RHEL5
in an environment like the one I'm describing.

I'd be interested in what others have done about this. Turn off
mlocate? Prune the paths?

Thanks for reading,

-Deke


                

_______________________________________________
rhelv5-beta-list mailing list
rhelv5-beta-list@redhat.com
https://www.redhat.com/mailman/listinfo/rhelv5-beta-list

Reply via email to