On Tue, 2009-04-07 at 14:24 -0400, Oleg Drokin wrote: > Well, what the stat actually meant to do is "give me the file > information > as it is now". By the time it returns, the data is stale anyway, and the > longer your path from the user app to the actual file storage, the > more potentially out of date the information is. > NFS just takes it to an extreme case and introduces an assumed validity > timeout. > While I do not directly oppose such a flag, I really do not see huge > value > in it. I wonder what is the specific usecase do you have in mind? The default behaviour of stat() on NFS is to do a revalidation of the cached data (by which I mean that we issue an RPC call if and only if the cache has timed out, or if it is known to be invalid). The AT_STRICT would be used by the application to tell NFS that it must retrieve the cached data from the server. One instance where this is useful would be the case where you're doing a distributed compile: the application knows that the file may have changed on the server, and wants to force the kernel to check mtime. Cheers Trond -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
