[162] in athena10
Re: Filsys Hesiod pointers in Athena 10
daemon@ATHENA.MIT.EDU (Greg Hudson)
Mon Apr 14 10:59:29 2008
From: Greg Hudson <ghudson@MIT.EDU>
To: Timothy G Abbott <tabbott@MIT.EDU>
Cc: athena10@MIT.EDU
In-Reply-To: <Pine.LNX.4.64L.0804131740230.12114@vinegar-pot.mit.edu>
Content-Type: text/plain
Date: Mon, 14 Apr 2008 10:56:37 -0400
Message-Id: <1208184997.5864.14.camel@error-messages.mit.edu>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
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
