Andy,
as for Intel Israel, we almost don't have NFS at all (200Gb in NFS vs
~8Tb in AFS).
We don't see administration overhead with it, since AFS gives much more
flexibility to both administrators and customers:
user-transparent data migration;
an ability for on-line backups;
data replication that provides both load balancing and robustness of
critical data;
global name space without automounters and other add-ons;
@sys variables for platform-independent paths to binary location;
enhanced security;
client-side caching;
etc.
We don't feel that AFS disk space costs more then NFS one.
It definitely shouldn't be treated as "one fits all" solution. And it has
its own problems. But, if you are not satisfied with AFS - first of all, try
to work more with AFS owner at your site to tune your clients and servers
configuration. You may really want to use local disks (/tmp or /scratch) as
a location for your interim data, and copy your final files to AFS.
In any way, feel free to ask me any Intel/AFS-specific question.
Gregory Touretsky
IDC Computing / Systems Engineering Group
Unix Server Platforms
[EMAIL PROTECTED]
> (+) 972-4-865-6377, Fax: 04-865-5999
iNET: 465-6377, M/S: IDC-1B
-----Original Message-----
From: Glew, Andy [mailto:[EMAIL PROTECTED]]
Sent: Saturday, August 12, 2000 8:27 PM
To: 'Paul Blackburn'; [EMAIL PROTECTED]
Subject: RE: AFS slowness
> It would be better to compare like for like.
> Why do you compare a distributed filesystem with the local filesystem?
Because that's the comparison that matters to business.
E.g. I have the option of putting the source code that I compile
on either a local disk, or a networked disk of any stripe.
Networked diskspace has advantages, but they are not enough
to make up for the 4-16x decrease in performance that I measure.
So, the source code that I compile must live on a local disk,
and I'll go through other hoops for sharing.
Now, to share, although I cannot put the source code on AFS,
I could put the CVS repository on AFS (keeping the checked out versions
local); or, I could use CVS server.
Again, CVS server is 4-16X faster than AFS.
So AFS loses here.
The same line of reasoning applies to a number of other areas.
AFS solves no problems that cannot be solved other ways,
using local disks, NFS, etc., albeit requiring more human
intervention.
But AFS's lousy performance relative to NFS and local disk
means that AFS's advantages do not outweigh the loss of performance.
> I think a better comparison would be: AFS/DFS/NFS/CODA from
> the client machine.
(1) I disagree, as I try to explain above. Local disk is equally
fungible.
(2) Even comparing AFS vs. NFS, AFS loses badly at the local
cluster level. And, although AFS might win at the global level,
AFS performance is bad enough that hand-rolled schemes - replicating
read-mainly data via FTP to local disks - suffices to make our
simulations run 2X faster than when run out of AFS.
> Have you looked at running the Andrew Benchmark [1]?
It's not the benchmark I am interested in.
I am the client - the guy who gives IT money to buy
AFS disks, or NFS disks, or local disks. I know what my applications
are. I have timed my applications - running full system makes,
running simulations - on AFS, NFS, and local disk. AFS loses badly.
---
Actually, this is the sort of thing that you describe
with Notes - move the Notes client binaries to local
disk, and then leave only the shared data. A lot of the
stuff that used to be on AFS has been replicated to
NFS at local sites in this way - e.g. NFS uin California,
NFS in Oregon, NFS in Israel, rather than AFS everywhere.
NFS still allows some sharing of diskspace to be done,
and is still faster than AFS.
But here's the real gotcha:
*** We've got to have local disk.
*** For LANFS, NFS beats AFS by at least 2X.
So, we use NFS.
(A lot
*** CVS server gives us access to version controlled shared
data.
*** We have hand-rolled replication solutions for the most
important stuff.
Because AFS doesn't solve the whole problem in a performing manner,
and because the whole problem can be solved without AFS;
because AFS has a lot of sysadmin overhead, and because it's
a hassle to split disk space up into separate pools of AFS and NFS;
AFS goes lower and lower on the priority list until it falls
off the ZBB.
