Date: Thu, 27 May 1999 11:33:03 -0400 (EDT) From: Zhihui Zhang <zzhang@cs.binghamton.edu> To: Ville-Pertti Keinonen <will@iki.fi> Cc: hackers@FreeBSD.ORG Subject: Re: A bug in namei cache? (stale entries) Message-ID: <Pine.GSO.3.96.990527110156.5144C-100000@sol.cs.binghamton.edu> In-Reply-To: <867lpufysx.fsf@not.demophon.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 27 May 1999, Ville-Pertti Keinonen wrote:
> zzhang@cs.binghamton.edu (Zhihui Zhang) writes:
>
> > Suppose you want to mv a directory file (with subdirectories) to another
> > name (it is like grafting a subtree to another point), the namecache
> > associated with the source directory file will be purged by calling
> > cache_purge() (done in ufs_rename()?). However, the routine cache_purge()
> > does not purge cache entries recursively down the subtree. Will this
> > result in a lot of stale entries in the namecache? FreeBSD 3.1 no longer
>
> The name cache only caches component names, not paths, so the entries
> are still valid.
>
Thanks for your reply. I understand now that the namecache only acts on
individual component names, not on the entire pathname. The following is
based on my understanding:
Suppose, you have a directory hierarchy a -> b -> c. In each of a, b, and
c, we have the following files:
a: ., .., a1, a2, a3, b (a1, a2, a3 are not directory files)
b: ., .., b1, b2, b3, c (b1, b2, b3 are not directory files)
If I do a "mv a a_new", then cache entries for a, a1, a2, a3, b will be
purged from the cache. Although b is purged from the namecache, we can
still find it by other means (e.g. ufs_ihashget() called by ffs_vget()).
So the entries for b1, b2, b3, c are still useful. So the namei cache
will not contain any stale entries.
Am I right?
-Zhihui
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.3.96.990527110156.5144C-100000>