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

[chas williams (contractor)]

In message <369570000.1088523600@endicott>,Chaskiel M Grundman writes:
>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

i didnt want to do actually do a FlushVCache() but just get the client
to check to see if the server has a different version.

>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 think about it some more it does seem silly.  i guess i keep
forgetting that nfs has to manage the cache, while the afs client is
already doing this.

>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?

i dont know the history on this one.  i guess someone was trying to use
the dnlc as a speedy check to see if a dentry is valid.  but later 
decided to double check due an excessive number of misses i guess.