rlocate vs. mlocate

[Miloslav Trmac]

Hello,
Nathan Grennan napsal(a):
> Sometime in the last few months I got the impression that
> mlocate would do what rlocate does.
I have no idea why...

> rlocate seems like the ultimate solution with it's use
> of inotify for real time results.
Note that rlocate actually doesn't use inotify.

>  Why isn't Fedora moving to rlocate? Hopefully it isn't a case of not
> invented here, since I notice the mlocate author is a Red Hat employee.
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