afs-client-inline-bulkstatus-rpc-support-
20010926
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.
====================
This delta was composed from multiple commits as part of the CVS->Git migration.
The checkin message with each commit was inconsistent.
The following are the additional commit messages.
====================
create audit event for inlinebulk
====================
rename spare2