[9] in Locker Maintainers
Re: attaching lockers before use
daemon@ATHENA.MIT.EDU (Nathan J. Williams)
Tue Nov 25 20:10:37 1997
To: Erik Nygren <nygren@MIT.EDU>
Cc: locker-maintainers@MIT.EDU
From: "Nathan J. Williams" <nathanw@MIT.EDU>
In-Reply-To: Your message of "Mon, 24 Nov 1997 21:26:22 EST."
<199711250226.VAA01645@zocalo.mit.edu>
Date: Tue, 25 Nov 1997 20:10:30 EST
> I hope this doesn't start a religious war,
> but should we require users (or programs)
> to attach lockers before running programs out of them?
>
> More practically, should binaries have /afs/.../foo/bar paths
> or /mit/foo/bar paths hard coded into them (eg, for shared
> library search paths)?
Yes, we should require that lockers be attached before
runnning programs out of them. The simple reason is that there's no
other way to guarantee that the contents of the locker are there, and
assumming the AFS path is completely wrong. For example, when the ILG
networking was much slower, I mirrored several lockers on our side of
the slow link and modified local attach.conf files to use the local
lockers instead of using the ones in AFS. This made the machines
faster and greatly decreased load on the network. I also mirror
lockers onto my laptop for disconnected operation, and do a similar
attach.conf hack.
Even within AFS, problems can arise with authentication; while
most people don't notice this, since most lockers are in one or two
cells that have been authenticated to already, it's a real issue and
I'm convinced that going through the attach abstraction is The Right
Thing.
This implies that programs should always use the
/mit/locker/foo paths to get at their files, as there is no other
reliable way for them to find files in that locker *.
Read lockers(7) and obey. It's a good abstraction, and it's
officially supported.
> Suggestions and comments are welcome.
People interested in some past discussions of this should read
back transactions in the athena-ws discuss meeting.
- Nathan
* I'm skirting the issue of multiple filsys entries that mount to the
same place, but I'm hoping that it doesn't happen for "production" use
very often.
