[OpenAFS] Puzzler: lack of access to AFS files

[Jeffrey Altman]

Rodney M. Dyer wrote:
> At 02:28 PM 12/17/2007, Jeffrey Altman wrote:
>> For each file operation CIFS sends anywhere from three to five requests.
>>  As a result there is significant overhead that increases the round trip
>> time and limits the overall throughput.
> 
> What I'm getting at is that once a 100 MB file is opened and is being
> actively read from the server, if at any time your CPU is idle op'ing,
> waiting on the file contents from the server, then there is nothing you
> can do to improve on that.  CPUs and memory bandwidth are so fast these
> days that the biggest "cost" is in I/O where the CPU sits and idles its
> time away.  The only thing you do by improving the fetch/request
> algorithm is make Windows more efficient at performing other application
> operations, not your own.

That is not true at all.   If the CIFS interface reads 64KB at a time
and refuses to request the next 64KB until the previous one has been
delivered and the CM is reading 1MB at a time, then there is significant
overhead caused by the CIFS interface.  Why should I lose hundreds of
microseconds per 64KB simply because the CIFS protocol is dumb?

>> > On a related note, I've always wondered why the AFS file servers do not
>> > have "read cache" on the server side, so when one person requests a
>> > file, the second person sees the same file from the servers cache.  Or
>> > is that handled by the server OS cache (via the swap)?
>>
>> I would hope your file server's operating system provides file caching.
> 
> Block caching, not file caching.  The problem here is that the OS cache
> can't see inside the contents of the vicep to perform file cache
> operations.

You wouldn't do file caching in the file server.  you would perform
block caching.   I'm not going to cache a 250GB file, I'm going to cache
that parts of the file that have been used recently.

>> And when you copy the MSM or MSI to local disk it works or when you run
>> the install from a .readonly volume it works from a volume in which
>> the client user only has 'rl' privileges.
> 
> Not always.  The previous error mentioned in the last message was from
> just such a volume.

Then file a bug report because otherwise I have no idea I should be
looking for issues.

>>   If you try installing from a read/write volume and the application
>> can't obtain the lock it wants, you get that error.
>>
>> We don't have byte range locking on the file servers.  When we do, this
>> will get better.
>>
>> In the meantime, don't use read/write volumes for distribution of
>> .MSI/.MSM packages.
> 
> We never do that, we always use "RO" replications for distribution of
> application packages.  And the access is usually "system:anyuser rl" or
> "install_account rl".  There should be no locking issues here.