[OpenAFS-devel] Re: [OpenAFS] Linux kernel panic, OpenAFS client, gconf

[Chaskiel M Grundman]

--On Tuesday, June 29, 2004 09:39:12 -0400 "chas williams (contractor)"
<chas@cmf.nrl.navy.mil> wrote:

> 
> if dp's inode happens to be a directory shouldnt we avc->states &= ~CStatd
> to force the client to go back to the server to get a new copy?  should 
> this also be done to the parent inode as well?

For one thing, vcp->states &= ~CStatd won't invalidate our cached data.
That only forces us to call FetchStatus. If the server says that the
dataVersion is the same as the data that we have cached, the cache will be
used.

It also doesn't really make sense in this case. Unlike nfs, afs_lookup()
does not call a server-side lookup RPC unless it's talking to a DFS server.
It parses the (likely cached) directory locally. Why do you want to decide
that this cached data is invalid based on results obtained from using it?

Now that I've looked at the code, there is something else that I think is a
potential problem: We call osi_dnlc_lookup without checking to see if
parentvcp is CStat'd. I'm not sure why this optimization is even done. No
other platform's osi_vnodeops call the osi_dnlc functions directly. It does
not seem like there would be all that much extra overhead if we just called
afs_lookup to start with instead of inlining the cache lookup. Is the
afs_AccessOK() that big of a deal?