[163] in athena10

home help back first fref pref prev next nref lref last post

Re: Filsys Hesiod pointers in Athena 10

daemon@ATHENA.MIT.EDU (Timothy G Abbott)
Mon Apr 14 19:43:56 2008

Date: Mon, 14 Apr 2008 19:43:12 -0400 (EDT)
From: Timothy G Abbott <tabbott@MIT.EDU>
To: Greg Hudson <ghudson@mit.edu>
cc: athena10@mit.edu
In-Reply-To: <1208184997.5864.14.camel@error-messages.mit.edu>
Message-ID: <Pine.LNX.4.64L.0804141201150.17283@vinegar-pot.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

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
>
>

home help back first fref pref prev next nref lref last post