rlocate vs. mlocate

[Nathan Grennan]

Miloslav Trmac wrote:
> Some history:
>
> I decided to write mlocate as a "for fun" project at the time an
> audit-based locate replacement was proposed for the Summer of Code, in
> order to have something different for speed comparison.  I did look at
> existing alternatives with minimal run-time overhead (the possible
> audit-based locate would have an always-running daemon); a kernel module
> and a daemon didn't fit my idea of minimal overhead, so I have ignored
> rlocate.
>
> I was ready to write off the development time of mlocate as a "personal
> fun project, not paid by Red Hat", if it wouldn't be a noticeable
> improvement.
>
> The decision happened basically like this:
> mitr> I'd like to replace slocate by mlocate for FC5 and beyond.
> mitr> [mlocate is a noticeable incremental improvement over slocate].
> decision makers> OK, makes sense.
>
> It seems mlocate is working well; people now complain about makewhatis
> taking long time instead of updatedb :)
>
>
> That's the mostly unbiased part, the rest is my, obviously biased, opinion.
>
>
> I have now taken a very quick look at rlocate; note that I haven't
> actually tried it.
>
> - rlocate requires it's own kernel module; the Fedora kernel maintainers
>   frown on external modules, why isn't it merged upstream?
> - "At the moment the stacking with other security modules is not
>   implemented", in other words rlocate can't be used with SELinux.
> - I'd like to see some numbers.  Was the run-time overhead ever
>   measured?
> - The rlocate module uses \n to separate reported paths, but \n is
>   a valid filename character.  (This is of course fixable and not
>   a long-term concern, but it worries me such bugs are there after
>   a year of public releases.)
> - The code is based on slocate.  One of the benefits of mlocate is that
>   it is not based on slocate :)  Basically the only part of slocate that
>   could be reused in mlocate was configuration parsing and exclusion
>   handling, and that code was really better to rewrite from scratch
>   (e.g. look at #135952).  Call that NIH if you want.
>
>
> Generally, I think mlocate and Beagle together cover the problem space
> quite well:  Beagle is the "GUI search", full-featured, for people that
> need to get their work done and don't worry about every last bit of
> performance.  mlocate is the exact opposite, for command-line users who
> know the limitations and are prepared to accept them in exchange for
> almost no overhead.
>
> I'd hate to run a daemon snooping on all file activity only to run a few
> locate searches for non-moving system files a week; I happen to know
> where my own files are.
>
> Finally, "Why isn't Fedora moving to rlocate?" is not the right
> question.  I don't think it was ever decided that "Fedora isn't moving
> to rlocate"; in particular I'm sure a Fedora Extras package of rlocate
> would be welcome, then we would have something to compare.
> 	Mirek
  Ah, just for the type of response I was hoping for and expected. If 
rlocate uses a kernel module, instead of inotify, then I agree it isn't 
ideal. I would say as expected the focus is too much in the gritty 
programming details, and not the big picture which tends to be a common 
problem.

  It sounds like someone still needs to write a inotify version of 
locate. I have no problem with a light weight daemon that would just 
reindex the locate database based on information feed to it by the 
kernel via inotify. It would be an almost instantaneous replacement for 
both find and locate. I don't think beagle is quite the proper solution, 
at least from what I have seen of it. It is too focused on file formats 
and searching inside the file, where as most of the time you just need 
to find the file by name, especially as root. Another nice thing would 
be if such a daemon existed, tie find into for the more powerful 
searches based on more than just filename. I think that would settle the 
issue completely.