Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 17 Oct 2007 05:28:37 -0700
From:      Alfred Perlstein <alfred@freebsd.org>
To:        Ceri Davies <ceri@submonkey.net>
Cc:        cvs-src@FreeBSD.org, Stefan Esser <se@FreeBSD.org>, cvs-all@FreeBSD.org, src-committers@FreeBSD.org
Subject:   Re: cvs commit: src/usr.bin/locate/locate updatedb.sh
Message-ID:  <20071017122837.GM31826@elvis.mu.org>
In-Reply-To: <20071016225906.GK23043@submonkey.net>
References:  <200710152209.l9FM9Jv3017150@repoman.freebsd.org> <20071016102013.GE23043@submonkey.net> <4714F06B.7070702@FreeBSD.org> <20071016225906.GK23043@submonkey.net>

next in thread | previous in thread | raw e-mail | index | archive | help
* Ceri Davies <ceri@submonkey.net> [071016 15:59] wrote:
> On Tue, Oct 16, 2007 at 07:10:03PM +0200, Stefan Esser wrote:
> > Ceri Davies schrieb:
> > > On Mon, Oct 15, 2007 at 10:09:19PM +0000, Stefan Esser wrote:
> > >> se          2007-10-15 22:09:19 UTC
> > >>
> > >>   FreeBSD src repository
> > >>
> > >>   Modified files:
> > >>     usr.bin/locate/locate updatedb.sh 
> > >>   Log:
> > >>   Make the updatedb script installed as /usr/libexec/locate.updatedb
> > >>   inspect all local file systems, not only ufs and ext2fs. A number
> > >>   of local file systems has been added over time, and at least zfs
> > >>   has the potential to become a popular choice. Without this change
> > >>   a ZFS root file system causes the script to ignore all file-systems
> > >>   and leads to an empty locate db. (An alternative is to add all the
> > >>   relevant file systems individually, which means that at least zfs,
> > >>   xfs, ntfs, ntfs-3g, msdosfs should be added, probably more).
> > > 
> > > This now includes /dev, /dev/fd, /proc, /compat/linux/proc, CD-ROMs and DVDs
> > > as well as duplicating everything in nullfs mounts, all of which are probably
> > > undesirable -- well, they are undesirable to me; whether they are to
> > > others is the question ;-).
> > 
> > Ok, thank you for the information. I did not notice this in my tests.
> > 
> > I'm not sure what the "local" pseudo fs-type is meant to be used for.
> > Currently it appears to be identical to "not-remote" (which is what
> > the locate db update tries to avoid, due to high network load and
> > scan time).
> > 
> > I plan to fix this within the next 24 hours (if anybody thinks it needs
> > to be backed-out immediately, I'm willing to do this, but I'd rather
> > put in the correct fix instead.
> > 
> > Two possibilities: We could have another pseudo fs-type in find, which
> > selects "real" file systems (and skips devfs, procfs, fdescfs, nullfs
> > and probably more). Scanning of removable devices is dubious, too,
> > independently of their file system. By selecting "local" and "disk
> > based" file systems (which would omit not only the pseudo file-systems
> > and nullfs, but also cd9660 and udf), no specific file systems needed
> > to be put into the script (and find would have the knowledge).
> 
> While userland can tell if a filesystem is pseudo or not, (see lsvfs),
> I'm not sure that we can reliably tell whether a device is removable or
> not (cf. my camera, USB key, iPod, etc.).

fstab(5) gives some hints, "noauto" would be a giveaway as well as
value of 0 for 'fs_passno' is also a hint.

-- 
- Alfred Perlstein



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071017122837.GM31826>