In message <[EMAIL PROTECTED]>,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. _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
