From owner-freebsd-hackers Fri May 28 0:48: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.oeno.com (ns.oeno.com [194.100.99.145]) by hub.freebsd.org (Postfix) with SMTP id 56DBC14D86 for ; Fri, 28 May 1999 00:47:59 -0700 (PDT) (envelope-from will@ns.oeno.com) Received: (qmail 6924 invoked by uid 1001); 28 May 1999 07:47:57 -0000 Date: 28 May 1999 07:47:57 -0000 Message-ID: <19990528074757.6921.qmail@ns.oeno.com> From: Ville-Pertti Keinonen To: zzhang@cs.binghamton.edu Cc: hackers@FreeBSD.ORG In-reply-to: (message from Zhihui Zhang on Thu, 27 May 1999 11:33:03 -0400 (EDT)) Subject: Re: A bug in namei cache? (stale entries) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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? Yes, except that the "other means" for finding b are more commonly by holding a reference to the vnode (open file handle, currenct directory) or just by searching the directory again. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message