[164] in athena10
Re: Filsys Hesiod pointers in Athena 10
daemon@ATHENA.MIT.EDU (Mitchell E Berger)
Mon Apr 14 20:20:24 2008
Message-Id: <200804150019.m3F0JdXg010052@oliver.mit.edu>
To: Timothy G Abbott <tabbott@MIT.EDU>
cc: Greg Hudson <ghudson@MIT.EDU>, athena10@MIT.EDU
In-Reply-To: Your message of "Mon, 14 Apr 2008 19:43:12 EDT."
<Pine.LNX.4.64L.0804141201150.17283@vinegar-pot.mit.edu>
Date: Mon, 14 Apr 2008 20:19:39 -0400
From: Mitchell E Berger <mitchb@MIT.EDU>
While we're on this topic, I guess I should toss in mention of something
else that I discovered while playing with it last night in the SIPB
office. As root (on zsr), I tried the standard invocation of attach
to mount the readwrite copy of the mimeutils locker.
It reported that it was doing what I'd asked it to do, and did not indicate
any errors. What actually happened was that the automounter attached the
RO copy of the locker. So, essentially, attach silently failed. On top
of that, the attachtab reported that the RW copy was attached, so any program
that uses either output of attach or liblocker or what-have-you gets incorrect
information. And, if you try to detach a locker, it will also silently
fail to really get rid of the /mit symlink even though the relevant entry
will be removed from the attachtab as if it had worked.
Whatever we end up doing, I think we need to end up in a consistent state
where we don't have the automounter and an attachtab in disagreement about
lockers attached/mounted on the machine.
Mitch
> Apparently, the afuse code never "unmounts" volumes unless you unmount all
> volumes. However, the sequence
>
> rm -f /mit/sipb
> ln -sf /afs/.sipb.mit.edu/project/sipb /mit/sipb
>
> works just fine with the afuse automounter.
>
> -Tim Abbott
>
> On Mon, 14 Apr 2008, Greg Hudson wrote:
>
> > I am personally happy with ditching locker priority and hesiod name !=
> > mountpoint support in order to yield a simpler system.
> >
> > However, a related issue came up on Zephyr overnight. If a locker is
> > important enough to be replicated in AFS, then the
> > default /mit/lockername path will be read-only. Historically, the way
> > to maintain such a locker involves doing (on a private machine):
> >
> > detach lockername
> > attach -t afs -m /mit/lockername -e /afs/.cellname/path/to/locker
> >
> > Such contortions may not be necessary to build most software today, but
> > they are also useful in order to test it before releasing the volume.
> >
> > This problem doesn't have to be solvable with the same interface. It
> > would be reasonable to tell people to become root and make a symlink by
> > hand, for instance. (That doesn't work with the autofs automounter when
> > I try it, but maybe it works for the afuse automounter.) Or there could
> > be a configuration file of lockers to attach read-write, and the afuse
> > automounter could consult the file and substitute /afs/. for /afs when
> > making the symlink; we would also need a way to prod the automounter
> > into re-mounting.
> >
> > On Sun, 2008-04-13 at 18:33 -0400, Timothy G Abbott wrote:
> >> There's been some discussion on locker priority and related filsys pointer
> >> issues in Debathena forums, and I thought I'd bring it up here.
> >>
> >> Currently, neither the autofs automounter nor the afuse automounter that
> >> I've prototyped (and seems to not have several minor autofs problems)
> >> respect the last two fields of locker filsys entries. The second-to-last
> >> field, the mount location, cannot be reasonably supported in the
> >> automounter framework, since it would not be useful for attempts to access
> >> /mit/oracle8 to mount something at /mit/oracle. So, I don't see any
> >> choice but to deprecate this feature in Athena 10.
> >>
> >> The second field in Hesiod filsys entries that doesn't work correctly in
> >> the automounter future is the priority field. Currently, the first line
> >> returned by DNS is used in both the autofs and afuse implementations.
> >> One could easily change these implementations to instead pick the line
> >> with the lowest priority number. However, I believe that correctly
> >> implementing fallback correctly for either of these systems will be
> >> a substantial amount of work.
> >>
> >> From a usage perspective, Linerva and Debathena have never gotten
> >> complaints that they ignore the priority field, and in fact, I wasn't
> >> certain whether or not autofs parsed the priority field until I read the
> >> code today.
> >>
> >> Assuming that we do not implement fallback, the priority field in filsys
> >> entries will be completely useless once everything is migrated to Athena
> >> 10, since the point of the priority field is to support fallback. I'm not
> >> convinced fallback is an important feature to preserve, since AFS supports
> >> replication natively, and NFS lockers are nearly extinct.
> >>
> >> This leaves us with a few options:
> >> 1) Implement fallback in our automounter
> >> 2) Implement priority resolution but not fallback in our automounter
> >> 3) Use the current implementations, and when convenient change all
> >> existing Hesiod entries using priority to only offer one option.
> >>
> >> I currently prefer (3) because it results in a simpler system with
> >> negligible loss in functionality, but don't have strong feelings on the
> >> matter and don't know how many filsys entries use priority today.
> >>
> >> Thoughts?
> >>
> >> -Tim Abbott
> >
> >
