Paul Wankadia <jun...@google.com> writes: > On 1/16/09, Ian Kent <ra...@themaw.net> wrote: > >>> Sure, just read the whole map. Even large maps aren't that big. What >>> are we talking, 10k? 50k? You're better off reading the whole thing in >>> at once. >> >> Yeah, that would be best. I'll have a think about how to detect when to >> do that. Maybe we can rip out that convoluted change detection logic for >> file maps, after all they should be fairly simple to deal with. > > If inotify can play nicely with the existing event handling, then it > could be worth considering.
Ian was coming up with a scheme to only read part of the map. Because the map is just a flat file, he surmised that a lookup could happen like so: first lookup, start at the beginning of the file walk the entries, adding each to the cache until you find the entry you're looking for cache the offset into the file and stop reading When a cache miss comes in, start reading the file again at the last offset (so long as the file hasn't changed on disk) My argument is that you're not really saving much. Just cache the whole file. I agree that you probably want to detect changes, still. For that, you can use mtime or inotify. You could make a case for either side, though I think I'd argue for keeping the mtime approach (as the map may change multiple times before we actually try to read it, and doing the read in the lookup path really shouldn't be that big of a deal). Of course, I haven't profiled this, so that may be worth doing. Cheers, Jeff _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
