On Fri, 2009-05-29 at 15:04 -0700, Simon Kirby wrote: > On Fri, May 29, 2009 at 02:36:46PM -0400, Trond Myklebust wrote: > > > That is most likely to be a consequence of poor mtime resolution on the > > server (i.e. the directory mtime failing to change because the file > > creation occurred within < 1 second of the 'rm'), combined with negative > > lookup caching. > > As in "ls --full-time" shows 0 for the fractional second part? > > Hrm, I thought newer ext3 had nanosecond mtime, but it seems not... No. You'll have to migrate to ext4 (or xfs) if you want finer grained timestamps. > > Try using the '-olookupcache=positive' or '-olookupcache=none' mount > > options (requires a relatively recent version of nfs-utils). > > After backporting nfs-utils, either of those options seem to this > particular case work as desired. Excellent! > > I guess all of the attribute-caching-related options are unrelated to > this case. Is this consistent with older operation and that of other > OSes? It might be a little surprising for some (me) when "noac" still > ends up doing some caching. noac is all about attribute caching, whereas this is lookup/dentry caching. You can compare it to data caching: 'noac' doesn't force the cache to be flushed on every read() request, but it does force the mtime to be checked, and so cache consistency is relatively stronger (provided the mtime is accurate enough). 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
