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.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
