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 ? > > > (not restore) could cause completely unrelated files (which we update every > > 5 minutes using some simple raw shell scripts) to remain out-of-sync > > with other NFS clients - that is, client A changes the content every 5 min > > but client B and C see it only after 1-2 hours. Seems somewhat new and > > unrelated to the restore case of above - as restore does change directory > > content (and that's where the problem lies) but backup merely changes > > the file's mtime probably (but not even sure it does that - maybe leaves it > > unchanged) > > > 3) The other part of my issue which I still don't understand is, why a backup > I've no idea why the other clients aren't seeing a change in this case. > I certainly cannot reproduce this with my own setup. > > With the default acdirmin/max settings, the clients should not be > caching the mtime for longer than 1 minute. While they might be blind to > the directory changes during that time, they should at least see it > after the minute expires. Forget this issue - I found the problem - not related to NFS Cheers, Stefan -- 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
