[OpenAFS] NFS/AFS Translator
Mitch Collinsworth
mitch@ccmr.cornell.edu
Thu, 16 Aug 2001 09:20:57 -0400 (EDT)
One thing I remember being a big problem with the translator is that
it is easy to cause cache corruption when reading files accessed via
a path that uses an @sys. Specifically, if you have more than one
sysname-value client using the same cache manager you lose. This
includes an NFS client of one sysname-value using the translator
running on a machine of a different sysname-value, if the translator
machine is also using its cache manager for local work.
The workaround I ended up having to use for this was a separate
translator for each client sysname-value, preferably one of the same
sysname-value as the clients it served. If it couldn't be the same
sysname-value, say because the client doesn't exist for that OS, I
had to dedicate a machine to just being a translator for that
sysname-value and allow no other use of that machine.
[And yes this was all reported to Transarc but never resolved. In
theory it should still be an open bug, but it's been years since
anyone cared.]
-Mitch
On Thu, 16 Aug 2001, David Thompson wrote:
>
> While I wouldn't recommend or use the translator in an authenticated
> environment (can you say "Evil"?), we have made excellent use of it in
> read-only environments, specifically re-sharing installation images (Red Hat,
> *BSD, etc.) from afs through nfs.
>
> In an appropriately limited role, I think the translator is a Good Thing(tm).
>
> Dave
>
> "Steven N. Hirsch" wrote:
> >On Wed, 15 Aug 2001, Garance A Drosihn wrote:
> >
> >> Back when we (RPI) first started using AFS, we also used the
> >> NFS/AFS translator for some platforms. Our experience with
> >> it was not particularly wonderful. I wouldn't plan to use it
> >> for anything, based on our experience.
> >
> >I'll second that with a vengeance! At work, I actually tried to implement
> >a production process which involved a translator connection. I found it
> >to be slow and quirky. Fortunately, the need for it disappeared soon
> >afterward when a native AFS client became available (Digital Unix 4.0.)
> >
> >
> >
> >_______________________________________________
> >OpenAFS-info mailing list
> >OpenAFS-info@openafs.org
> >https://lists.openafs.org/mailman/listinfo/openafs-info
>
>
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>