OpenAFS CVS Commit: openafs/src/afs/VNOPS by shadow

[cvs@GRAND.CENTRAL.ORG]

Update of /cvs/openafs/src/afs/VNOPS
In directory GRAND.CENTRAL.ORG:/data/sb/openafs/src/afs/VNOPS

Modified Files:
	afs_vnop_lookup.c 
Log Message:
DELTA afs-client-inline-bulkstatus-rpc-support-20010926
AUTHOR shadow@dementia.org

this cuts rpc traffic in half for directories on which you have
no permissions and is capable of doing more if a useful way can
be conceived of caching errors. 

currently bulkstat works thus:
say a directory has 100 files. bulkstat will on the first hit stat
the first 30 files, integrating the information if successful,
and when you hit file 31, repeat. meaning if you can read that 100 files
is 4 bulkstatus rpcs (3*30+10). if you can't, you do bulkstatus, get an abort,
then do fetchstatus on the file and find out why you lost. you go on and
try bulkstatus again this time for files 2-31 instead of 1-30. same failure,
meaning you do 2N rpcs for the N files. inlinebulk doesn't abort but instead
fills in stat info for any of the up to 30 files it can, and errors for
any it can't. 

currently the client will pull out any stat info filled in,
and then return the error from the first file, meaning if you can't
read the directory we do N inlinebulk rpcs instead of N bulkstatus +
N fetchstatus rpcs. if the errors for the other 29 could be meaningfully
cached (and you have to be careful not to pollute information
such that it's not useful for someone in a different auth context) then
we could get down to the same 4 rpcs we have for success, but that's an
exercise for later give how the cache manager works.


--- DELTA config follows ---
afs-client-inline-bulkstatus-rpc-support-20010926 openafs/src/afs/VNOPS/afs_vnop_lookup.c 1.14 1.15