Path: utzoo!attcan!uunet!mailrus!umich!terminator!dabo.ifs.umich.edu!rees
From: rees@dabo.ifs.umich.edu (Jim Rees)
Newsgroups: comp.sys.apollo
Subject: Re: reason to buy Apollos
Message-ID: <1990Jul12.181524.1462@terminator.cc.umich.edu>
Date: 12 Jul 90 18:15:24 GMT
References: <9007121442.AA01927@richter.mit.edu>
Sender: usenet@terminator.cc.umich.edu (usenet news)
Reply-To: rees@citi.umich.edu (Jim Rees)
Organization: University of Michigan IFS Project
Lines: 20

In article <9007121442.AA01927@richter.mit.edu>, krowitz@RICHTER.MIT.EDU
(David Krowitz) writes:
  It would be *much* cleaner if AFS did what Domain/OS does ...
  namely put the host entry directories in // rather than in /.

Actually, you might be surprised at how many programs break because of the
'//' notation.  AFS currently puts all the machine names in /afs.  But each
machine is not an equal member of a large distributed file system.  Instead,
it's much more of a traditional client/server relationship.  I don't
particularly like this aspect of AFS.

I've been running AFS for a couple of months on my Apollo and it's pretty
nice.  It uses large pages (64k) and caches them on a local disk.  Once your
cache is full it's plenty fast.  But it's got some strangeness, like no hard
links, no atime, and acls.  It's also got deviant links, but they're not as
flexible as Apollo's, since the only thing that can be substituted in is the
machine type.

The AFS selected by OSF as part of DCE will be considerably different from
the AFS 3.0 currently in use around the country.