[OpenAFS] Puzzler: lack of access to AFS files
Rodney M. Dyer
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
> > 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
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.