Date: Wed, 8 Sep 2010 08:18:58 -0400 From: John Baldwin <jhb@freebsd.org> To: src-committers@freebsd.org Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org Subject: Re: svn commit: r212293 - in head/sys: fs/nfsclient nfsclient Message-ID: <201009080818.58374.jhb@freebsd.org> In-Reply-To: <201009071429.o87ETjLq002398@svn.freebsd.org> References: <201009071429.o87ETjLq002398@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, September 07, 2010 10:29:45 am John Baldwin wrote: > Author: jhb > Date: Tue Sep 7 14:29:45 2010 > New Revision: 212293 > URL: http://svn.freebsd.org/changeset/base/212293 > > Log: > Store the full timestamp when caching timestamps of files and > directories for purposes of validating name cache entries. This > closes races where two updates to a file or directory within the same > second could result in stale entries in the name cache. While here, > remove the 'n_expiry' field as it is no longer used. > > Reviewed by: rmacklem > MFC after: 1 week Note that this only reduces races if the NFS server supports sub-second timestamps. FreeBSD NFS servers do not by default since the global vfs timestamp is only updated once a second by default. In particular, the name cache entries in the NFS client can become stale any time that multiple updates can happen to a directory within the same timestamp. Put another way, if a directory has multiple "states" that share the same timestamp, the NFS client may cache the earlier state until the next directory update. It may be worth adding an optional timeout on positive cache entries in the NFS client just as we support having a timeout on negative cache entries to limit the extent of such races at the expense of increased LOOKUP RPCs. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201009080818.58374.jhb>