[436] in Info-AFS_Redistribution
Re: AFS and NeXTs
daemon@ATHENA.MIT.EDU (Michael T. Stolarchuk)
Fri Nov 15 17:53:58 1991
To: Craig_Everhart@transarc.com
Cc: "Michael T. Stolarchuk" <mts@terminator.cc.umich.edu>,
In-Reply-To: Your message of "Fri, 15 Nov 91 14:05:41 EST."
Date: Fri, 15 Nov 91 16:33:07 -0500
From: "Michael T. Stolarchuk" <mts@terminator.cc.umich.edu>
"Here's another set of problems. What would the NeXT CM return for
readlink(2) for such a mount point? ... "
"One goal is to avoid doing remote GetTime (ping)
requests entirely for cells that you don't care
about, not simply pushing requests into the background."
Ok, so what do we man by "don't care about"? Could very well be
I'm complety off base. I don't mind. I've been wrong before.
Boy do I agree on not firing the GetTime... it would work
for me on my NeXT, but it wouldn't as every NeXT client in North
America would (but then again, how many NeXT machines are there?
I mean if we are really worried about congestion control, seems
NeXT already has a solution)
So I have to be wrong. I'm making the file servers work too hard.
But I don't like handing back symbolic links to the client. And
I want the 'cd's to work right when I get there (along with opens, etc).
The real concerns about not telling the whole stat truth have to
do with internal dependencides of the afs code on its own VOP_GETATTR...
ie: its not afs_getattr which is the culpric, but afs_GetVCache,
since it does the ..AFS_FetchStatus's on the remote servers...
Maybe the CM code can always deals with assumptions about junctions...
though I don't believe that. Gotta read more of the same code again...
So, gotta believe reuss, and say you don't do the FetchStatus's
on VOP_GETATTR's for AFS if its a mkmount...
mts.
