On Tue, 2009-08-25 at 18:01 +0200, Stefan Egli wrote: > Thanks Trond for the input! I've got just one more puzzle (s.below) > > On Mon, Aug 24, 2009 at 2:11 PM, Trond Myklebust wrote: > > > > On Mon, 2009-08-24 at 12:32 +0200, Stefan Egli wrote: > > > > > 2) I'm still not sure I understand that patch correctly though > > > (37d9d76d8b3a2ac5817e1fa3263cfe0fdb439e5): Would the tivoli restore > > > be able to mess with mtimes and *therefore* cause the 4-5 hour cache > > > inconsistency I'm seeing? If yes, would the patch then magically fix this? > > > > If tivoli is messing with the mtime, then it _might_ cause the > > condition, in a restore situation by changing the directory contents but > > not the mtime (which is what tells the NFS client and applications that > > the directory contents have changed). > > By looking at the ctime too, the client can always tell that something > > has changed, and thus clear its cache. > > I suspect, the problem I'm seeing could be similar to this one: > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/269172 > > What puzzles me with that 269172 bug is that it requires that you > first do a 'ls' on machine A - then do that script mentioned in the > bug on machine B - > and then do another 'ls' on machine A. This looks like with the first 'ls' > machine A fills its attribute-cache - which then later on becomes out-of-sync > with what the NFS server says. > > In my situation though, I'm not doing any ls in the subdirectories affected - > which would mean it's not 100% explainable with the above bug... bugger... > > or is it ? Yes. The NFS client will cache mtime whether or not you do an 'ls'. I suspect the only reason for the 'ls' in that launchpad bug report, is to force an mtime update (and to fill the readdir cache). Cheers Trond -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
