[3304] in Release_7.7_team
Re: Athena Disconnected Operation White Paper Draft 2.
daemon@ATHENA.MIT.EDU (Greg Hudson)
Sat May 25 13:02:23 2002
From: Greg Hudson <ghudson@MIT.EDU>
To: lcs@mit.edu
Cc: source-developers@mit.edu, release-team@mit.edu
In-Reply-To: <CMM.0.90.4.1022304388.lcs@defiant.mit.edu>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: 25 May 2002 13:02:19 -0400
Message-Id: <1022346139.3992.91.camel@error-messages.mit.edu>
Mime-Version: 1.0
When I wrote the netscape-local script, I thought about ways to do
generic locker mirroring, and found most of them wanting. Expanding
disk capacities might help somewhat, but there are still a lot of
problems.
> We can take advantage of the locker conventions to cache only the files
> useful on the local system, e.g. the arch/@sys subdirectory, and common
> subdirectories like share, man.. "etc". (Of course, sometimes the
> arch/@sys subdir has symlinks to other architectures so those would have
> to be followed and their targets pulled in as well.)
Particularly with large third-party software lockers, this won't help
much. The real platform-dependent stuff is typically under some
directory like "distrib"; what's under "arch" is some scripts which set
up some environment variables to point into /mit/lockername/distrib.
> Read-write lockers are a bigger problem.
Too big to solve, I think. Anything we could do might be useful to the
occasional power-user but would be too confusing for the naive. That's
not a very good use of resources.
> For that matter, we could leave named alone and simply write a separate
> local-named, and the state change script would shut down one and start
> the other.
That's an interesting idea, although I imagine it leading to race
conditions at network restoration time. (Maybe not. Does named only
fork itself after it's ready to listen to queries? Anything else would
seem to lead to race conditions at boot time.)
