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? >> Question 4: If we'd somehow manually detected such a directory >> content inconsistency - would there be something like a 'hey NFS >> client, flush all NFS caches NOW' thing? > > No. unmount / mount would - but that's obviously not feasible. bugger there's nothing for that... >> 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 ? 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
