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 -- 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
