Hi, It's me again. I'm catching up on 'man 5 nfs' and reading all the input I found wrt the NFS directory cache issue so far. So this is hopefully a condensed set of findings and questions ;) 1) As I understand, the Linux version we're using (2.6.24-24-generic) does not contain the patch 37d9d76d8b3a2ac5817e1fa3263cfe0fdb439e51 - which only made it to the kernel 2.6.30, right? 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? 3) The other part of my issue which I still don't understand is, why a backup (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) 4) If I see this correctly, the acdirmin/acdirmax parameters could not prevent a situation 2) of above? 5) Would rdirplus be of any help here at all? 6) Regarding the echo 3 > /proc/sys/vm/drop_caches issue: > Only if you are certain that there are no processes actually using that > directory or any of its subdirs/files. What happens if there are processes still having files open in subdirs? Would probably create .nfs files - but would it otherwise work - or corrupt read/written data? Cheers and thanks a lot for the help! 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
