[52] in Info-AFS_Redistribution
Re: Andrew File System?
daemon@ATHENA.MIT.EDU (daemon@ATHENA.MIT.EDU)
Tue Jan 15 10:59:49 1991
Date: Tue, 15 Jan 1991 09:45:55 -0500 (EST)
From: Kris Olander <kriso@northstar.dartmouth.edu>
To: olsen!nagler@cs.utexas.edu (Robert Nagler)
Cc: Kris Olander <kriso@northstar.dartmouth.edu>, info-afs@transarc.com
In-Reply-To: <1183@brchh104.bnr.ca>
Excerpts from netnews.comp.sys.sun: 11-Jan-91 Andrew File System? Robert
Nagler@cs.utexas. (1375)
> I have a few questions about the Andrew File System. I would like to hear
> replies from people who are using the AFS on SPARCs--Transarc and OSF
> people don't bother replying.
> 1) Can AFS completely replace NFS including booting? Assume 200MB local
> disks on all machines. I don't mind wasting a couple of MB for root, but
> would like to access /usr/{share,...} via AFS, i.e. I'd like 150MB left
> over for the "cache" on the local disk.
Technically speaking, NFS isn't what boots a diskless machine. I believe tftp
as well as other mechanisms take care of the actual boot process.
But, to answer your question, AFS should have some minimal root on the
local disk in order to get the machine up and running enough to start the AFS
daemons. If you really streamlined, I'd believe you could get away
with less than
10Meg of local root space. However, the more system files that reside
in AFS space,
the greater demand you'll be placing on the network (more cache hits, etc.)
I think our best configurations are our Sparcstations with (2) 107meg disks.
We do have some HP systems running HP's CNODE diskless environment
with AFS mounted via and AFS/NFS translator which runs on some other
diskFULL AFS client. The AFS/NFS translator works pretty well, however we
haven't stressed tested that Transarc product as much as we would have
liked. It
appears that Transarc isn't going to provide a version of /bin/login
that works over
an AFS/NFS translation. But, this means that NFS _is_ necessary for AFS
to work
on a diskless system.
150Meg for cache is probably overkill. I believe that Transarc
recommends something
much less than this.
We have man pages, src, sys, X11 source, ATK source, /usr/ucb,
/usr/local, (...) all
residing in AFS (along with all our user accounts). It's quite
flexible in this regard.
> 2) We don't have any servers, i.e. all the shared disks are on
> workstations that people use. Is it possible to use the one disk as a
> cache while using the server software on another? The file system should
> be identical on all machines.
If I understand this question, your asking whether or not someone could
be working
on a system that was acting as the AFS file server and never notice that the
system is any different from other AFS client systems. Correct?
If that's the case, there is no problem. All our servers are also
clients. The software
that controls whether a system is a server or a client are independent from one
another. I could just as easily be working on one of our servers and
never know
the system was the server. However, to best utilize the system, you
would probably
want the server system to have more disk space since, generally, most
user accounts
would lie in AFS (ie: on the server disks).
> 3) Can you cross-mount and what happens when a "server" goes down? Is it
> like NFS in that everything waits for that server? Do you have to play
> special games when booting?
You're getting into a gray area here. You can't think of AFS as being
similar to NFS.
I don't quite understand what you mean by 'cross-mount'ing, but AFS
doesn't ever
get "mounted". The AFS daemon starts and if you have a /afs directory
and everthing
is set up properly, you should be able to access the AFS tree.
The clients don't wait for the server in the same fashion as NFS. Of
course, if there
is something wrong with the file server (be it and AFS, or NFS, or XYZ
fileserver)
you will probably have some problems.
If you have clients which are basically standalone machines (ie: they'll
boot up without
having to depend on the fileserver), and the AFS fileserver is down, the
local AFS
daemon will just keep trying every so often to connect up with the file
server. The
machine functions just fine, nothing gets locked up waiting for the
server to come back
on line. How usefull the standalone machine is when there isn't a
fileserver depends
on what resides on the local disk. If all our servers went down, even though
the machines would boot up fine, we'd be sitting around waiting for the
server to
come up because all our user files and many of our X11/ATK binaries all
reside on
the file servers.
> 4) Do you notice a reduced network load when using AFS in comparison to
> NFS? (This is really a loaded question, because site
> configurations/network use varies widely.)
I haven't done any objective testing of this, so if anyone can add more
info here
please do so. From a subjective view, :) I know that the machine I'm working
on almost always has my resource files (.login, .cshrc, ...) locally
residing in the
cache which definitely speeds up login. Other commonly used files (like ATK
and AFS binaries) also will almost always be cached on my system which
speeds up startup times. Of course, if I had a cache that was less than
10 meg,
the cacheing benefits would probably dissappear.
> 5) What are the administration headaches?
Backups. Transarc is working on this though. Nothing prevents a person from
using 'tar' for backups, but you can't use 'dump' to backup files in AFS -- the
physical data on the servers are not stored in 'normal' UNIX fashion.
Tar doesn't
work for us because it would take TOO long, and file protection could prevent
all files from being backed up.
> 6) What's your configuration (briefly)? Are you using it with
> SPARClones?
IBM (RTs, 6152s, RS/6000), HP9000 (340), Sun (3/280, 3/60, 4/110,
Sparcstations 1),
DEC (3100).
Actually, (cough, cough) the Sparcstations are my favorite platform.
> 7) Do you recommend purchasing AFS as a part of the OSF/DCE or directly
> from Transarc? What's the support like?
I don't think I'd ever recommend getting involved with a first release of a
semi-radically new OS. Unless you are willing to be a quasi-beta tester
and your
user population is tolerant of glitches in the operating system, I'd
wait a while
before jumping into OSF/DCE. Let the major gweepers handle the ironing out
of OSF/DCE. As far as I can tell, OSF/DCE is going to have some novel
concepts.
This is by no means a complete response to your questions. It would take me a
couple of days to thouroughly answer your questions. I would suggest that you
get some more detailed literature from Transarc. I also have to say that I'm
biased since we've been using AFS for the better part of four years now, and
wouldn't dream of using anything else.
Kris Olander
Sys. Eng., Project NORTHSTAR
Dartmouth College
------------------------------------------------------
"My thought, my whole thoughts, and nothing but my thoughts,
so help me God", -- My stdclaimer