[159] in athena10
Filsys Hesiod pointers in Athena 10
daemon@ATHENA.MIT.EDU (Timothy G Abbott)
Sun Apr 13 18:34:23 2008
Date: Sun, 13 Apr 2008 18:33:39 -0400 (EDT)
From: Timothy G Abbott <tabbott@MIT.EDU>
To: athena10@mit.edu
Message-ID: <Pine.LNX.4.64L.0804131740230.12114@vinegar-pot.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
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
