Why updatedb doesn't traverse my external HD?

JB jb.1234abcd at gmail.com
Sat Dec 24 22:03:27 UTC 2011


Marko Vojinovic <vvmarko <at> gmail.com> writes:

> ... 
>  `/media', type `tmpfs'
>  => type matches, dir `/media'
> ...done
> Skipping `/media': in prunefs
> </quote>
> 
> I am not sure how to read this, but it appears that /media somehow matches the 
> tmpfs, which gets excluded. So now I have three questions:
> 
> (1) Why is /media considered to be tmpfs? AFAIK, it is just a directory under 
> my root partition, which is ext4. What am I missing?

I already explained that in a post in a different branch.

> 
> (2) How do I fix this? I don't want to remove tmpfs from prunefs. Is there a 
> way to reconfigure the /media to not be tmpfs? Or is there any way to force 
> updatedb to traverse the contents of /media regardless of pruning rules?
> 

I was wondering about this:
updatedb.conf(5)
...
      PRUNE_BIND_MOUNTS
              One of the strings 0, no, 1 or yes.  If PRUNE_BIND_MOUNTS  is  1
              or  yes,  bind  mounts are not scanned by updatedb(8).  All file
              systems mounted in the subtree of a bind mount  are  skipped  as
              well,  even  if they are not bind mounts.  As an exception, bind
              mounts of a directory on itself are not skipped.

              By default, bind mounts are not skipped.
...

This is of interest to me:
...
                                                         As an exception, bind
              mounts of a directory on itself are not skipped.
...

I tried to bind mount /media or /media/NETBSD_51 on itself and it did not work.
Perhaps I am missing something here or the feature does not work ?

> (3) What exactly changed here between F14 and F16? In F14 the same 
> configuration used to work, ie. /media was not recognized as tmpfs, AFAIK.

Under F14:

$ mount
/dev/sda2 on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
/dev/sr0 on /media/NETBSD_51 type iso9660 (ro,nosuid,nodev,uid=500,utf8)

# cat /etc/updatedb.conf
PRUNE_BIND_MOUNTS = "yes"
PRUNEFS = "9p afs anon_inodefs auto autofs bdev binfmt_misc cgroup cifs coda
configfs cpuset debugfs devpts ecryptfs exofs fuse fusectl gfs gfs2 hugetlbfs
inotifyfs iso9660 jffs2 lustre mqueue ncpfs nfs nfs4 nfsd pipefs proc ramfs
rootfs rpc_pipefs securityfs selinuxfs sfs sockfs sysfs tmpfs ubifs udf usbfs"
PRUNENAMES = ".git .hg .svn"
PRUNEPATHS = "/afs /media /net /sfs /tmp /udev /var/cache/ccache /var/spool/cups
/var/spool/squid /var/tmp"

# updatedb --debug-pruning
...
 `/media/NETBSD_51', type `iso9660'
 => type matches, dir `/media/NETBSD_51'
...
Skipping `/media': in prunepaths
...

Note:
1. /media/NETBSD_51 , being of "type" iso9660, is pruned per PRUNEFS
2. /media is pruned per PRUNEPATHS

# cat /etc/updatedb.conf
PRUNE_BIND_MOUNTS = "yes"
PRUNEFS = "9p afs anon_inodefs auto autofs bdev binfmt_misc cgroup cifs coda
configfs cpuset debugfs devpts ecryptfs exofs fuse fusectl gfs gfs2 hugetlbfs
inotifyfs iso9660 jffs2 lustre mqueue ncpfs nfs nfs4 nfsd pipefs proc ramfs
rootfs rpc_pipefs securityfs selinuxfs sfs sockfs sysfs tmpfs ubifs udf usbfs"
PRUNENAMES = ".git .hg .svn"
PRUNEPATHS = "/afs /media /media/NETBSD_51 /net /sfs /tmp /udev
/var/cache/ccache /var/spool/cups /var/spool/squid /var/tmp"

...
 `/media/NETBSD_51', type `iso9660'
 => type matches, dir `/media/NETBSD_51'
...
Skipping `/media': in prunepaths
...

Note:
Regardless of /media and /media/NETBSD_51 being in PRUNEPATHS, the PRUNEFS
takes care of /media/NETBSD_51 due to fs type, *before* PRUNEPATHS takes care
of /media (but not of /media/NETBSD_51) due to its path.

CONCLUSION:
Due to /media being a *generic* (top level) qualifier, having fs types as its
sub-qualifiers when /media is actually populated (mounted), the updatedb
should process PRUNEPATHS *before* PRUNEFS for it to work correctly.
It is a bug, up to and inclusive F16, and I guess F17 too.

> ...

JB




More information about the users mailing list