[165] in athena10
Re: Filsys Hesiod pointers in Athena 10
daemon@ATHENA.MIT.EDU (Timothy G Abbott)
Wed Apr 16 16:03:32 2008
Date: Wed, 16 Apr 2008 16:02:43 -0400 (EDT)
From: Timothy G Abbott <tabbott@MIT.EDU>
To: Mitchell E Berger <mitchb@mit.edu>
cc: Greg Hudson <ghudson@mit.edu>, athena10@mit.edu
In-Reply-To: <200804150019.m3F0JdXg010052@oliver.mit.edu>
Message-ID: <Pine.LNX.4.64L.0804161557120.27282@vinegar-pot.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
It would probably not be difficult to add additional code to the afuse
automounter to update the attachtab when it makes a symlink, if that's the
route we want to take. Currently, it's a 13-line perl script.
-Tim Abbott
On Mon, 14 Apr 2008, Mitchell E Berger wrote:
> 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
>>>
>>>
>
