[OpenAFS] Puzzler: lack of access to AFS files

Rodney M. Dyer rmdyer@uncc.edu
Mon, 17 Dec 2007 14:54:22 -0500

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.

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

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

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