Beau Henderson writes:
> On Tue, Jul 29, 2008 at 8:38 AM, Andrey Falko <[EMAIL PROTECTED]> wrote:
> > On Mon, Jul 28, 2008 at 2:29 PM, Andrew Gaydenko <[EMAIL PROTECTED]> wrote:
> > >
> > > Are there (emerge/revdep-rebuild/other portage tools related)
> > > situations when fs db creating is useful?
> >
> > I believe there are. I used to use slocate when I had tens of
> > thousands of mp3s and other media files. Its a lot of times its faster
> > to use slocate or locate than a find to find a certain file.
>
> I believe the OP's intentions are to determine if slocate would have any
> benefit specifically for portage related utilities.
>
> And with that, there would not be any benefit to the average user IMHO,
> as slocate is updated usually nightly ( when installed ) and as such if
> the utilities were using the results obtained from that utility, it might
> apply changes which would be detrimental to the system, assuming changes
> have been made to portage or installed apps since the updatedb run.
Right. Still, I like having the locate command. About those nightly
updates.... they suck, updatedb creates much load on my systems, and the
updatedb cronjob always just kicks in when I don't want it. But I think I
just found a solution to this:
emerge -C slocate && emerge mlocate && time updatedb && time updatedb
mlocate is supposed to be compatible with slocate, but the updatedb command
runs much faster. Well, the first time it takes a little longer, but after
this it's fast. The website says:
mlocate is a locate/updatedb implementation. The 'm' stands for "merging":
updatedb reuses the existing database to avoid rereading most of the file
system, which makes updatedb faster and does not trash the system caches
as much.
I don't know why it is faster to scan a directory hierarchy for its files
than to verify which of the files in la list are still there and which new
ones are there, but I saw the difference.
Wonko
