On Fri, 2009-08-21 at 21:08 +0200, Stefan Egli wrote:
> Hi Trond,
>
> > It sounds like a bug. You don't mention which client you are using.
>
> from uname:
> Linux (Ubuntu) 2.6.24-24-generic #1 SMP Tue Jun 30 19:54:36 UTC 2009
> x86_64 GNU/Linux
>
> from mount:
> type nfs (ro,tcp,rsize=8192,wsize=8192,nfsvers=3,addr=192.168.XX.YY)
>
> > You can tune the amount of time the client caches information by using
> > the 'ac*' mount options. In this case, you will want to adjust the
> > values of 'acdirmin' and 'acdirmax', probably setting them to zero.
> >
> > 'man 5 nfs' should provide you with more information.
>
> Ok, so setting acdirmin=0 and acdirmax=0 would mean no directory
> content caching, right?
No directory _attribute_ caching, which again should mean that we check
if the parent directory mtime has changed on each lookup.
> >> Question 5: any of this related to commit 37d9d76d8b3a2ac5817e1fa3263cfe
> >> 0fdb439e51: NFS: flush cached directory information slightly more readily. ?
> >
> > You client should be seeing mtime changes when you are creating new
> > files, so it shouldn't need to look at the ctime.
> >
> > The only time when ctime changes are relevant are if you use 'rsync' to
> > copy the files without specifying --omit-dir-times.
> > IOW: if something is explicitly setting the mtime on the directory.
>
> Would have to check if that applies in our case. We're doing
> backup/restore from tivoli (tsm) - maybe that guy is to be blamed
> for not correctly updating mtime/ctimes ?
The restore will probably mess with the mtime, in which case you should
probably apply the above commit (applications cannot change the ctime).
Cheers
Trond