On Fri, Jan 16, 2009 at 5:39 PM, Ian Kent <ra...@themaw.net> wrote: > > 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.
Thanks! 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. Is there a design document for autofs v5 that you're permitted to share?
_______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
