Since a number of people have asked to see a summary, and Robert
said it was ok to forward his response I will. I guess I'll give
AFS 3.3 a whirl.
Roland
--- Forwarded mail from Robert Malick <[EMAIL PROTECTED]>
To: Roland Schemers <[EMAIL PROTECTED]>
Excerpts from mail: 4-Apr-94 AFS/NFS questions... Roland
Schemers@Slapshot (1837*)
> Due to the fact we have a lab of 15 Indigos we needed to integrate
> in our AFS environment (~18000 accounts, ~4000 AFS home directories,
> the rest in NFS) and they must run IRIX 4, we had to go with the AFS/NFS
> translator (you can stop laughing anytime).
> Anyhow, I have to two questions:
Welcome to the world of the AFS/NFS translator. :-) We here at NIH have
been supporting our SGI machine via a translator for years. Debugging
them with Transarc as we go. :-)
> 1. Why aren't the protection bits correctly mapped via the tranlator?
Since AFS doesn't know anything about group or other bits and since NFS
doesn't know about AFS ACLs, the translator simply duplicates user bits
to group and other. And yes, this is a security risk as soon as one
gets out of AFS space not to mention the havoc it plays with remote
commands like 'rsh', 'rlogin', etc.
Transarc "fixed" this in AFS 3.3. If you run AFS 3.3 on your translator
machine, then you can use the "-noconvert" option with the 'fs' command,
to tell it to not propagate the permission bits, but to send the bits
that are really there. We have yet to try it out here at NIH. Here is
the section from the manual page for fs.
> -noconvert
> determines whether the group and other bits on
> exported files and directories are converted to match
> the user bits. By default, the group and other bits
> on exported files and directories are made to match
> the user bits. Specify this flag to leave the bits as
> they are in AFS.
> 2. It seems like there is a big problem with cache consistency. A grad
> student has been compiling and running stuff from AFS and he
> can reproduce problems where if he compiles a program and
> immediately runs it the process gets killed the first time it runs
> but if you wait a few seconds (5-6) it always works. Its like
> Its like the compiler/linker exists and the program is getting loaded
> into memory before the AFS cache is flushed.
The delay you are noticing is due to NFS caching. NFS has a caching
scheme as does AFS. One has to be patient with NFS so that it has time
to write it's cache to the translator machine. The Sun NFS server
(translator) returns a "I wrote the file" even though it hasn't yet.
This is done to speed up the NFS world. So you have to wait for this
to happen also. And on top of it all, if you are accessing those files
>From another AFS client, you have to wait til the AFS cache writes
things to the fileservers
> I've heard horror stories about AFS/NFS translator. Do these problems
> sound familiar??? Are there any NFS mount options that would help?
> How about AFS 3.3?
As for the caching problems the best thing I can tell you is to get NFS
to not cache as much as you can. I haven't done any studies on it, but
by not running 'biod' may help. I wish Sun NFS had the ability to do
write throughs to disk like SGI NFS servers have. I thought I
remembered hearing something about Sun implementing something like this.
In this way, the Sun NFS server (translator) will not let the NFS
client continue til it actually HAS written the file to its disk. SGI
uses the 'wsync' export option on their NFS servers to do this (I refer
you to SGI reference manual "NFS and NIS Administration Guide and Man
Pages") but look for it on Sun NFS in the future. This would be
something to implement if it ever happens. At least one of your delays
would be over.
If these are the ONLY problems you see using the translator then you are
VERY lucky. There are many more lurking that, when they happen, you are
left scratching your head for a while.
Hope I have helped.
BTW: Feel free to repost this to info-afs (or alt.filesystems.afs) if you want.
Rob,
aka "Singin' Translator Blues"
--- End of forwarded mail from Robert Malick <[EMAIL PROTECTED]>
--
Roland J. Schemers III | Networking Systems
Systems Programmer | 414 Sweet Hall +1 (415) 723-6740
Distributed Computing Operations | Stanford, CA 94305-3090
Stanford University | [EMAIL PROTECTED]
