On Fri, 2009-01-16 at 15:24 +0900, Ian Kent wrote: > On Fri, 2009-01-16 at 17:04 +1100, Paul Wankadia wrote: > > On Fri, Jan 16, 2009 at 3:21 PM, Ian Kent <ra...@themaw.net> wrote: > > > > > + if (me && ctxt->mtime <= me->age) > > > > > > You have to call stat(2) or fstat(2) at some point or else > > ctxt->mtime > > > will never change. > > > > > > We set the mtime when we read the entire map, see > > modules/lookup_file.c:lookup_read_map(). This is totally > > taking > > advantage of the existing code to read a map that is marked as > > stale. It > > doesn't however attempt to simplify the code which works out > > if we need > > to mark the map stale but we probably don't want to anyway as > > we need to > > ensure we use up to date entries for lookups done while > > waiting for the > > map update to be done. > > > > Sorry, I don't understand how that condition will evaluate to false. > > You won't read the map until ctxt->mtime changes, but it won't change > > until you read the map. > > Mmmm .. before that last change I was assuming the code which sets the > stale flag would cause the read but then I removed that bit and ... > oops!
Because, after a mount lookup we check the stale status and queue a map read if the map is stale. But then I went and removed the bit that sets the map stale because it's lazy in identifying if the map has changed so we could get quite a few mount lookups before a map read gets queued. I'll add back the stat(2) I originally had their before I posted the patch. I'm also thinking of checking if a map read task is in progress when a mount lookup comes in and waiting for it to complete before continuing with the lookup (to reduce the number of file scans a bit). But I'll need to have a look around to see if that will be a problem. Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
