[440] in Info-AFS_Redistribution
Re: AFS and NeXTs
daemon@ATHENA.MIT.EDU (Cal_Thixton@next.com)
Fri Nov 15 20:59:58 1991
Date: Fri, 15 Nov 91 19:43:41 EST
From: Cal_Thixton@next.com
To: Wallace Colyer <wally+@andrew.cmu.edu>
Cc: Info-AFS@transarc.com, Cal_Thixton@next.com, Craig_Everhart@transarc.com,
Yes, Wallace, it is hard to admit to a design flaw and be forced to correct it than to
work around it later on when your install base is huge. I also agree with you that
having your cell pinged just because the top of your cell is being stat()'ed is wrong.
I prefer the philosophy of pushing off the work until you really need it (e.g. Mach
does not zero out memory when you allocate it, but when you try to touch it.
Autonfsmounter does not request a stat of a remote host or try to mount it until you
cd into it).
Being somewhat of a purist, I would be reluctant to put into Workspace special
knowledge of filesystem types when dealing wih services provided through the vnode
layer. Putting in code to deal with large file systems is an issue of scaling.
Putting in code to know when it was dealing with AFS versus NFS or even UFS, except
perhaps for those cases when dealing with oob (out of band) issues, does not seem
right. The whole concept of using vnodes was to hide these differences, right? Make it
look all the same (mostly)?
Changing the behavior of stat() is not a good option.
GUI's (graphical user interfaces) on filesystems are the way things are going. Since
none of the filesystems designed over the last 10 years had GUI's in mind and now they
are having a hard time coping. Were it the case that the filesystem could notify a
GUI of updates, then perhaps we'd have a smaller problem now, but we don't.
Today, 10% of the AFS install base are NeXT's. I'll argue that this number is growing
and will be over 25% by the end of 92. I know that the Workspace has had problems
with issues of scale when dealing with very large filesystems and many of them have
been addressed over the last 18 months. But I also know that these filesystems are
getting used in ways that differ from when they were originally designed. To date,
all of the things that have been fixed were all on the NeXT. And yes, there was plenty
to fix. When you are the first vendor to offer a GUI for a filesytem, you get that
privilege. But as some point, you need to go back and do some fine tuning of your
original design to adapt to the ways people want to use your work. Putting in special
cases to cope with old bugs is not a good way to do software engineering.
Give me arguments that apply to issues of scale and does not treat AFS as a special
case (but also applies to NFS, UFS, RFS, FTP...) and I'll get them implemented, but to
treat AFS differently would be a disservice to the whole philosophy that AFS was built
upon. And now would be a very good time to get these things addressed before the
install base mushrooms.
cal
Begin forwarded message:
Date: Thu, 14 Nov 1991 09:53:01 -0500 (EST)
From: Wallace Colyer <wally+@andrew.cmu.edu>
To: Info-AFS@transarc.com, Cal_Thixton@NeXT.COM, Craig_Everhart@transarc.com
Subject: Re: AFS and NeXTs
Cc: Info-AFS@transarc.com, mts@terminator.cc.umich.edu
What you are asking us to do is to change the semantics of the
filesystem used on this campus by thousands of people to accommodate one
machine type which does not want to accept that is can be both expensive
and unfriendly to do a stat operation on anything it sees. I really
don't want every next machine in every cell to stat my cell and have to
keep pinging the connection to see if it alive.
I we go off and fake directories for this machine type we would have to
support those path names on the other system types because users would
invariably start using the new names. Since our users spend a great
deal of time collaborating with other AFS sites those path names may
have to be exported to other sites.
Craig just got in my last point, which is that you seem to be handling
the case of the automounter in a much more hacked manner than I am
suggesting. If you are willing to handle that case you could do as
Craig suggests and make everything in /afs look like a directory without
stat'ing it.
My suggestion would be to add a configuration option, StatsAreExpensive,
which would have it not stat entries in the portions of the browser
window that do not represent the highest directory being viewed. That
would be a generic solution that handles any filesystem where
indiscriminate stats are expensive as in AFS.
The other suggestion of changing the behavior of stat to lie, how can we
do this? We do not know if you are the browser or not. Many people may
use stat to see if that directory is accessible requiring the real
information to be returned.
-Wallace
