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