[415] in Info-AFS_Redistribution
Re: AFS and NeXTs
daemon@ATHENA.MIT.EDU (Michael T. Stolarchuk)
Thu Nov 14 16:51:23 1991
To: Wallace Colyer <wally+@andrew.cmu.edu>
Cc: Info-AFS@transarc.com
In-Reply-To: Your message of "Thu, 14 Nov 91 09:53:01 EST."
Date: Thu, 14 Nov 91 15:18:14 -0500
From: "Michael T. Stolarchuk" <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'm not trying to make life difficult for anyone. There are some
different ways of solving some the problems we have, and some of the
ideas are worthless, and some have some merit... I have yet to see
one solution which is easy ...and strightforward ... and ...
I know you've noticed the NeXT machine defaultly does "ls" via "ls -F",
so that the first time a unsuspecting user does "ls /afs", he ends up pinging
all the file servers anyway...
And I really believe leaving /afs the same way for all users of the cell...
"The other suggestion of changing the behavior of stat to lie,
how can we do this?"
I never got to trying this to see how bad it was...
If the client does a stat on a 'fs mkmount' you can quess lots
of the elements of the stat, like directory, permission bits,
inode number, etc without actually getting the fields. At the same
time, one of the background daemons could be queued to get the
real bits associated with the mkmount... So what stat fields do
you think are 'important' in an fs mkmount...
# ls -lsd /afs/umich.edu
2 drwxr-xr-x 4 admin 2048 Oct 28 21:14 /afs/umich.edu
What uses rdev in the big file system? uid/gid aren't important either.
The stat's don't do access calls (ie you can't tell via the bits
whether you can *really* cd into that directory)... so why not lie?
Additionally, it the background daemon gets the stat, then it
has to keep worrying about the remote machine...
You could lie under administrator control (too!)
mts.
