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