[758] in Info-AFS_Redistribution
Re: mail & afs
daemon@ATHENA.MIT.EDU (Wallace Colyer)
Fri May 8 15:51:06 1992
Date: Fri, 8 May 1992 13:47:26 -0400 (EDT)
From: Wallace Colyer <wally+@andrew.cmu.edu>
To: Info-AFS@transarc.com
Cc: Info-AFS@transarc.com, "Michael Niksch" <nik@zurich.ibm.com>
In-Reply-To: <9205081537.AA14655@sayshell.umd.edu>
We are heavily dependent upon the Andrew Message Delivery System (AMDS)
which, as has been said on this list, stores mail and bboards in AFS.
The system has been an incredible success. We have over 6300 active
unique mail users per week, 4400 from Macs and PCs (with over 40,000
sessions). Mail and bboards have become an integrate part of the CMU
environment. The success has unfortunately shown its limitations. We
are planning to switch to a client/server mail solution like IMAP/POP
(IMAP is currently heading the list).
There are several problems with this type of service living on top of
AFS which in our environment outweigh the benefits that AMDS offers:
1) File Server Activity: arguably AFS performs the worst with files
read by lots of people and modified frequently. The AMS bboard system
stores files in AFS which lots of people read and are updated frequently
causing the fileservers to be constantly dealing with callbacks.
2) Cache Manager limitations: Though this improves with 3.2, AFS
performs miserably on multi-user client machines where lots of people
are simultaneously accessing the remote filesystem. AMS makes extensive
and often needlessly repetitive use of the filesystem and multiple AMS
users on the same machine easily make the machine totally unusable when
all they are doing is reading mail.
3) Non-AFS clients: In our environment there is a great demand for mail
access for Macs and PCs which do not have direct access to AFS. This
means they must go through intermediaries which access the filesystem on
their behalf to get mail. The intermediaries fall prey to the problems
of the Cache Manager limitation talked about above. They are multi-user
machines which only access AFS. (we have 14 Decstation 5000/125 to
serve as intermediaries for Macs and PCs and they still perform
miserably so we are buying 5 more).
4) You can't upgrade AFS without AMDS. AMDS is dependent on AFS
filesystem semantics. This means that changes in AFS often break
obscure parts of AMDS. With the DFS coming down the road it will
probably break and much work will need to be done to make it work.
5) When the filesystem is slow mail is slow. AFS is big and
complicated. It sometimes has problems. There is no need to have your
mail system stop working when the filesystem stops working. Since AMDS
can easily overload the filesystem, it is often the cause of the
problems.
6) AFS is a high bandwidth service: Mail and bboards should be
available to people from home over SLIP connections. Though the
University of Michigan has done quite a bit of work to make it better,
there is no reason to pay for all the overhead of AFS on slow networks
to read mail.
7) Remote dependencies: This mail had problems being sent out because
the address info-afs@transarc.com address had to be validated with the
transarc.com cell. I had to wait while my machine timed out with the
Transarc cell, then if I force it to be sent anyway it will sit here in
the queues until the fileserver comes back up. I guess this isn't much
different than the SMPT dependency, but the user doesn't have to wait
for the remote SNMP server to time out.
Mail need not be based on a complicated service like AFS. There are a
limited number of actions you want to do on mail. Simple protocol like
IMAP will suffice and make the mail system more widely available.
-Wallace
Ps. Sorry if I sometimes refer to AMS and other times to AMDS - I have
never understood which is which. AMS is the Andrew Message System and
AMDS is the Andrew Message Delivery System.
