Q: why is AFS so slow?
Where slow is:
a) compared to local disks on a client
b) compared to NFS across same network
c) compared to local disks on the AFS server
(I have personally measured a and b. Slowness c
is reported to me, and seems to be true based on
some other evidence, but I would be very interested
if anyone who has regular access to an AFS server
could measure it, i.e. measure the speed of accessing
an AFS disk, even though on the server, and accessing
a non-AFS disk on the same server (e.g. UFS))
Yeah, yeah: AFS provides much more functionality, sharing,
security... Nevertheless, I would like to understand
whence comes AFS's slowness.
E.g. if I am accessing files of, say, 100MB, and my local AFS
cache is of 200MB, large enough to hold all of the AFS files
I am accessing, and if I am the only person accessing these
files... why is AFS still 16X slower than local disk?
Should not all of the data be living in the local cache,
once accessed for the first time?
Or, is the AFS client stopping to ask the server "is this okay"
on a regular basis, adding network roudtrip latency to what
would otherwise be a purely local action?
---
I ask because I am an AFS advocate - at least, I am an advocate
of wide area network filesystems (I wish there was an alternative
to AFS).
But, it is very hard to argue for WANFS when disks on AFS servers
are so costly (because of server price margins), and when AFS performance
is just so slow.
It used to be that our mantra was "keep everything on networked
filesystems (like NFS and AFS)."
Then it became "work locally, but keep master copies, like the CVS
repository, on AFS (and check in regularly". Motivation: development
speed. Compiles on local disks are often found to be 4-16X faster
than compiles on AFS.
Then it became "work locally, and check in via CVS server (ssh,
pserver, etc.)". Motivation: CVS server accesses local disks on the CVS
server,
as opposed to AFS. Again, significantly faster, especially when
performing actions like "cvs tag" that scan the repository
but make only minor changes. Function shipping rather than data
shipping (rather than shipping of lots and lots of unnecessary data).
At first, we might keep the CVS repository on AFS. But then it was
discovered that non-AFS file access was faster even on the AFS server.
So, the CVS repository is moved off AFS. This helps both actual
work, and backup speed.
Penultimately, only "golden" versions were kept on AFS. But these aren't
very useful, since they can always be extracted from CVS. So now, it
appears
that there is no need for AFS, if you have CFS server... ???
What bugs me about this is that CVS server really is a network filesystem.
Just one with complex primitive operations (higher performance)
and less transparent semantics. Grepping a CVS repository is not so easy...
you need to check out and grep locally, which you may not be able to do...
Basically, WANFS access allows you to use generic tools; otherwise you're
wired into what has preseen.
