cache_purge > cache_zap segmentation fault
alih at internetDog.org
Thu May 8 12:03:25 PDT 2003
(not quite sure which'd be your first name. 'phk' is how I remember
On Thu, May 08, 2003 at 08:08:40PM +0200, Poul-Henning Kamp wrote:
> In message <20030508140210.B26126 at internetDog.org>, Ali Bahar writes:
> >I still need to understand the difference between a vnode's
> >v_cache_src and v_cache_dst (IOW, a namecache's nc_src and nc_dst),
> One is for the chain which a (directory) vnode sources, the other
> is the chain where the (any type) vnode hangs from it's parent
Hmm. Forgive me, but I went over the above sentence 20 times, and I'm
still not sure.
Given the vnode for /usr/src,
- is its v_cache_dst a linked list of namecache entries for /usr,
- & its v_cache_src a linked list of namecache entries for /usr/src/sys ?
Or vice versa? Or neither?
Why would there be a _chain_ of namecache nodes for a file's parent? I
assume that symbolic links are involved (from another dir to this file).
Would you know if the 5.0 modifications could fix this problem? My
reading of the problem is: As a new file/dir is being accessed, a new
vnode is obtained thru getnewvnode. But vnodes are recycled, and so
the 'new' vnode has to be cleaned up. This means that all its old
associations/resources have to be deleted. What is happening in
cache_zap, is that its "source vnode list" of namecache entries is
being deleted. In the deletion, it comes across a dangling/corrupt
Thank you very much for your help. Much appreciated.
Jesus was an Arab.
More information about the freebsd-hackers