bugfindutils - Bugs: bug #8599, updatedb / locate is unusable over...

 
 

bug #8599: updatedb / locate is unusable over NFS

Submitted by:  Bruno Haible <haible>
Submitted on:  Fri 16 Apr 2004 08:16:08 PM UTC  
 
Category: locateSeverity: 3 - Normal
Item Group: NoneStatus: Postponed
Privacy: PublicAssigned to: None
Originator Name: Open/Closed: Open
Release: 4.2.0Fixed Release: None

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Sun 11 Apr 2010 11:55:55 AM UTC, comment #5:

updatedb would probably be best rewritten. I'm going to mark the updatedb-related bus as "Postponed" in order to consider them all in a batch, when I get around to the rewrite.

(Leslie P. Polzer did start on a rewrite some time back as part of the Summer of Code but there are some updatedb-related issues his changes don't resolve yet, I think)

James Youngman <jay>
Project Administrator
(Why is this post is considered to be spam? Users may have reported it to be spam or, if it has been recently posted, it may just be waiting for spamchecks to be run.)
Spam content:

Yes, incomprehensibly, why in this happened the stop? Interesting before the end, but here foots.
______________________________________________________________________
http://www.veromaxx.com/ - Pharmacy Online, Cheap drugs at Sexual Health

Anonymous
Thu 30 Aug 2007 03:37:05 PM UTC, comment #4:

I like the idea of using .locatedb for the mounted directories. But why stop at that? Why not implement, that if a directory contains a file called .locatedb then it should be assumed it contains the database for the subtree under this dir?

It should then simply be merged into the main locate database.

I got this idea when my machine was highly irresponsive due to running updatedb on a huge directory structure that only changes once every month (and therefore is almost read-only).

Ole Tange <tange>
Tue 25 Apr 2006 03:31:22 PM UTC, comment #3:

I have added an item to the GNU Summer of Code project suggestions which is a project to fix this problem. Would you be willing to mentor it?

See http://www.gnu.org/software/soc-projects/ideas.html

James Youngman <jay>
Project Administrator
Mon 22 Nov 2004 09:01:59 PM UTC, comment #2:

A configuration file is a good approach for dealing with read-only
media (CD-ROMs) or with volumes that are offline (a collection of
CD-ROMs, for example).

However, it doesn't answer the usecase of NFS mounted volumes properly.
I mean, I use mount/umount typically twice a day, plus plugging in
USB sticks volumes as well. It's not realistic to expect that a user
will update a configuration file each time he mounts or unmounts a
volume. So it should be the 'mount' program which updates the configuration
file automatically. If you get these changes accepted by the 'mount'
maintainers - fine with me. But there's already an agreement that
'mount''s modifications to /etc/mtab are an anachronism, because /proc
(or system calls) provides the same information in a more accurate way.
Therefore I think it's worth thinking about a solution that works without
cooperation from the user or from the 'mount' program.

Regarding newline in pathnames: I think this is an irrealistic requirement.
We are talking about mountpoints here. Such mountpoints are usually listed
in /etc/fstab, where (AFAIK) no provisions for escaping, newlines, not
even spaces, are made.

Bruno Haible <haible>
Mon 08 Nov 2004 09:45:25 PM UTC, comment #1:

Bruno,

I would rather do this with a configuration file which lists the various databases which must be searched, the path prefix which must be removed (=the location of the filesystem on the server) and the prefix which must be prepended on the client (= the mount point on the client). This delivers the functionality you're looking for in a more flexible way. However, I need to figure out a useful configuration file format.

This is easier said than done, because it needs to cope with filenames containing newlines and so forth, and yet be easily human-maintainable. Any suggestions?

James.

James Youngman <jay>
Project Administrator
Fri 16 Apr 2004 08:16:08 PM UTC, original submission:

The updatedb / locate approach is unusable in practice on
systems with large (> 1 GB) NFS mounted volumes, simply
because of the limited speed of 'find' over NFS.

Here is a suggestion for making it work in this situation as well:
Declare that it must be the server's responsibility to maintain
the locatedb at a fixed location under the mountpoint, for
example at {mountpoint}/.locatedb.
1) Define precisely this location, {mountpoint}/.locatedb or so.
2) Change the 'locate' program so that it looks not only in the
global /etc/locatedb, but also iterates over each NFS-mounted
filesystem and looks there as well.
3) Provide an updatedb-exports script, intended to be run on
the server, that iterates over all NFS-exported volumes
(showmount -e) and updates the .locatedb there.
4) Explain all of it in the documentation.

Bruno Haible <haible>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by jay (Posted a comment)
  • -unavailable- added by tange (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 11 Apr 2010 11:55:55 AM UTCjayStatusNone=>Postponed
    Mon 08 Nov 2004 09:45:25 PM UTCjayReleaseNone=>4.2.0
    Fri 16 Apr 2004 08:16:08 PM UTChaibleCarbon-Copy-=>Added bruno --AT-- clisp --DOT-- org

    Back to the top


    Powered by Savane 3.1-cleanup