On Fri, 2015-10-16 at 13:34 -0700, Junio C Hamano wrote: > David Turner <dturner@xxxxxxxxxxxxxxxx> writes: > > > The problem is: > > > > trash directory.t7063-status-untracked-cache$ diff trace trace.expect > > 3,4c3,4 > > < directory invalidation: 1 > > < opendir: 1 > > --- > >> directory invalidation: 2 > >> opendir: 2 > > > > > > I can repro on a SSD. > > > > I had to try many times to reproduce (I think even more the second > > time). I just ran the test in a while loop until it failed. > > > > I suspect that the kernel might be a bit slow to update the mtime on the > > directory, but I have not yet been able to repro, and I don't understand > > why it only happens in this one test, since sparseness should be > > completely unrelated. > > If you are invalidating your cache based on mtime of the directory, > an operation within mtime granularity can cause you to miss it, > unless you try to be conservative and do the "assume invalid if > racy". And if you do "assume invalid if racy", the result will > become timing dependent. You may end up invalidating more than > absolutely necessary, i.e. the test writer may have known that at > least 1 must be definitely stale at that point in the test, but > if another directory was iffy and the code played safe, you would > see one more invalidation than expected (which would lead to > scanning the directory, hence one more opendir). > > Is that what is going on here? The test has a sleep to avoid this. Looking at it, I think it just needs one more sleep. Testing now; if correct, I'll send a patch. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html