[6111] in Release_7.7_team
Re: Reworking liblocker
daemon@ATHENA.MIT.EDU (Bill Cattey)
Thu Dec 4 16:47:38 2008
From: Bill Cattey <wdc@MIT.EDU>
To: release-team@mit.edu
Cc: morzinski@mit.edu, ghudson@mit.edu, athena10@mit.edu
In-Reply-To: <200812041750.mB4HoYAt008314@outgoing.mit.edu>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Thu, 04 Dec 2008 16:46:52 -0500
Message-Id: <1228427212.32231.41.camel@cheshire-cat.mit.edu>
Mime-Version: 1.0
X-Spam-Flag: NO
X-Spam-Score: 0.00
The following message is long and may not go anywhere.
Still I feel compelled to add it to the conversation.
I am concerned that if we change attach to infer a mount point from a
location that we're throwing away an important part of the Hesiod
abstraction that enables us to separate filesystem location from mount
point.
In hallway chat, broder made the point that /mit as implemented in
debathena is really an abstract filesystem used as an access point for
filesystems accessed by attach. If I understand the fuse implementation
correctly, we're leveraging simple stock issue code to get 80% of the
user-visible functionality of attach.
Hesiod/attach was originally a particular triple:
Type Location Mount Point
Type enabled rich parsing of location and mount point names.
Mount point was the tie-in to the UNIX filesystem abstraction.
Location could be any old thing.
MUL was created to do load balancing and robustness.
We're pretty much learned that doing this sort of thing on the client
side doesn't work as well as having the server side offer one location
with its own idea of replicas. MUL is fading away and
that's just fine.
Presumably FUSE and other auto-mounter technology is rich enough that we
can support more than just AFS mounts if there is compelling reason to
in future. (In my ignorance, maybe it already does.)
I can see using attach/hesiod to ease a transition of the MIT enterprise
filesystem changes from AFS in the future. So making sure that Athena
10, debathena and their successors can handle more than just AFS is
important.
In the early days when attach was used to mount system packs served up
in byte-order dependent remote virtual disk packs, with server-imposed
limitations on names, there was compelling need to de-couple name from
mount point. Jacob's analysis of present usage shows that there is only
a minority of lockers using this de-coupling, and this thread has worked
around to asking the question, "Is there compelling need to continue
offering this de-coupling?"
In hallway chat with broder, I myself offered a counter-example. The
few people who want a different mount point probably don't want to take
the trouble to contact Central Services with a hesreq to get it.
So:
/mit is a virtual filesystem under debathena
common convention is to have a filesystem location that can almost
universally map into a /mit mount point.
There is resistance these days to utilizing attach as a means of
allowing non-root users to make symbolic links into privileged
directories.
Names and locations are conflated all the time. After all, everybody
uses URLs as if they are names. There is no need for the URN side of
the design, right?
My inner digital library researcher says, "Keep name and location
separate!" My inner pragmatist says, "Shed what is not useful."
For now, I'd feel more comfortable keeping the attach -m option, and in
having the Athena 10 implementation pull the mount point from the filsys
tuple if it can be done without a lot of code, and if it isn't a serious
security compromise.
But I don't feel as strongly about this change as I did about detach.
-Bill
On Thu, 2008-12-04 at 12:50 -0500, ghudson@MIT.EDU wrote:
> > It's probably reasonable, but it is a functional change that should
> > be considered carefully.
>
> A bit of perspective here:
>
> Athena 9.4 has a lot of machinery in it which allows you to do
> particular things in particular ways. This is good for continuity for
> past users of Athena 9.3, 9.2, 8.x, etc.. but it is also cumbersome
> and costly to maintain.
>
> The major vision of Athena 10 is to allow people to do almost all of
> the things you can do in 9.4, but not necessarily in the same way if
> it's costly to make that work. Compatibility is a design goal but not
> an overridding one.
>
> I don't think there is any compelling reason to support lockers which
> mount in /mit/foo for values of foo other than the locker name. It's
> not compatible with the new auto-mounter approach (since there is no
> reverse map) and it is not the common usage. There may be isolated
> exceptional cases, but in the long term it is probably better to
> address the exceptional cases than to continue to provide the
> machinery.
