[528] in Athena User Interface
Re: Medusa doesn't play well with AFS
daemon@ATHENA.MIT.EDU (Richard Tibbetts)
Mon Dec 18 12:36:02 2000
Message-Id: <200012181735.MAA26245@multics.mit.edu>
To: "Christopher D. Beland" <beland@MIT.EDU>
cc: aui@MIT.EDU, tibbetts@MIT.EDU
In-reply-to: Your message of "Mon, 18 Dec 2000 11:07:30 EST."
<200012181607.LAA25516@Press-Your-Luck.mit.edu>
Date: Mon, 18 Dec 2000 12:35:59 -0500
From: Richard Tibbetts <tibbetts@MIT.EDU>
On 12/18 Beland wrote:
> Ok, so I did a little more research into how Medusa works.
I have done none, and have never used Meduse, so anything I say is
based on conjecture. But I am probably right or very nearly so.
> I'm curious how it deals with changes to files since the last full
> index? Does something check to see what files have changed since
> then, or do I just lose?
It should almost certainly check the timestamp, which would make later
indexing very cheap, especially on something as small as an AFS volume
(usually 50 to 100 megs).
> - Run an indexer for the entire athena.mit.edu cell, and allow
> clients to connect to it via the network. (We do not trust root on
> local workstations.) This would provide functionality not unlike a
> web search, except somewhat more intrusive, since users often put
> files in their Public and www directories without telling anyone or
> any indexing services about them. It would also probably provide for
> very inefficient seraching. Who knows how long the indexing process
> would take. This would also represent a radical change in operation
> from Medusa's current architecture, and would require teaching it how
> AFS permissions work.
This is bad. Ops will laugh at you if you propose it. It is too
invasive, and adds another point of failure for the security of
peoples data.
> - Have an automatically-created index directory at the base of each
> locker; configure to search for this directory when searching files in
> that locker. Problem: Will only work in lockers that don't have more
> restrictive permissions set lower down, unless a fancy kludge is
> constructed to make multiple indexes, depending on access rights.
> (Ick!)
Ick is right. This also requires implementing a daemon, and doesn't
really add much value over the third option.
> - Allow users to run the indexer at some point when they are logged
> in. (Either automatically in the background after a certain interval
> since the last index, or perhaps on demand.) This solves the
> permissions problem, though does introduce a greater load on the
> servers if everyone is always indexing their files. If done on
> demand, users will lose the benefit of a fast search on a whim.
> There's also the question of whether or not to index files in group
> lockers the user accesses frequently.
I think that we should let the user index whatever lockers they want,
including their own. Medusa may need to be hacked to not explode when
it can't read something because of AFS but the unix permissions say it
can. GMC had this bug. Indexing should not be expensive after the
first time, so it can probably run in the background on every login,
assuming it doesn't mind being truncated if the user only logs in for
a few minutes.
There might be significant architectural barriers to this. If so, I
think that Eazel did it wrong. But if that is the case I don't think
that the value it presents to users is worth having MIT rearchitect
the system. However Eazel may decide that this functionality is in
their best interest, since AFS will be showing up in more and more
locations now that it is free.
tibbetts
-*- http://www.mit.edu/~tibbetts -*- finger tibbetts@monk.mit.edu -*-
