[424] in Info-AFS_Redistribution
Re: AFS and NeXTs
daemon@ATHENA.MIT.EDU (reuss@ni.umd.edu)
Fri Nov 15 05:05:04 1991
To: Craig_Everhart@transarc.com, wally+@andrew.cmu.edu, Info-AFS@transarc.com
Cc: Cal_Thixton@next.com
In-Reply-To: Your message of "Thu, 14 Nov 91 09:39:59 EST."
Date: Fri, 15 Nov 91 02:45:02 -0500
From: reuss@ni.umd.edu
>Craig_Everhart@transarc.com writes:
> Um, it seems that there's already some special code in place in
> Workspace to deal with ``automount'' names (under /Net). Is this a
> Workspace hack or what? What attribute is Workspace looking for in
> printing ``(automount)'' that it couldn't, or can't, print for names
> under /afs?
Out of curiosity I went poking around on my NeXT; it seems the
autonfsmounter sets the sticky bit on the symbolic link it makes in /Net.
The ls command and presumably the Workspace do an lstat, and if they find a
symlink with the sticky bit set they leave it alone. If you try a straight
stat on something in /Net, an nfs mount is done and the sticky bit is
removed from the link.
The Workspace also does some special case stuff somewhere to display the
"World" icon. By they way, anyone know why the icon for /afs is a '?' and
not a folder as you would expect ?
>wally+@andrew.cmu.edu writes:
> 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.
This sounds like a really great idea. Should speed browser times up a lot,
but you will still have a problem when users wonder into /afs and it becomes
the active "stating" portion of the browser.
> 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.
One idea I had on this would be to fake the stats *only* for cross-cell mount
points, but make it a setable option similar to 'fs setcell' for setuid
handleing. The number of times I would need stat information on the root of
a remote cell is very small. The number of times users still accidently do an
'ls -F' in /afs is a lot greater. Think of it as a good neighbor option that
will keep unnecessary traffic and load off other sites.
-Karl Reuss
University of Maryland
