Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 04 Sep 2014 16:24:15 +0200
From:      Hans Ottevanger <hans@beastielabs.net>
To:        =?UTF-8?B?RWR3YXJkIFRvbWFzeiBOYXBpZXJhxYJh?= <trasz@FreeBSD.org>
Cc:        freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org
Subject:   Re: [CFT] Autofs.
Message-ID:  <5408760F.2000607@beastielabs.net>
In-Reply-To: <20140904124330.GB4152@pc5.home>
References:  <20140730071933.GA20122@pc5.home> <53F0878E.3000401@beastielabs.net> <20140817145059.GA5497@pc5.home> <5407FFB0.80203@beastielabs.net> <20140904124330.GB4152@pc5.home>

next in thread | previous in thread | raw e-mail | index | archive | help
On 09/04/14 14:43, Edward Tomasz Napierała wrote:
> On 0904T0759, Hans Ottevanger wrote:
>> On 08/17/14 16:50, Edward Tomasz Napierała wrote:
>>> On 0817T1244, Hans Ottevanger wrote:
>>>>
>> [...]
>>>> Hi!
>>>>
>>>> Great to see a real autofs finally coming to FreeBSD.
>>>>
>>>> I already did some very cursory testing on a recent 11-CURRENT system
>>>> that I still happened to have and things with at least the /net map
>>>> look quite OK.
>>>>
>>>> I could do some more extensive testing if I could use some of my
>>>> 10-STABLE systems. I already checked that the patch applies cleanly
>>>> to a recent 10-STABLE (modulo a few offsets) and that both buildworld
>>>> and buildkernel succeed. Should I expect difficulties actually
>>>> running your autofs on 10-STABLE?
>>>
>>> No, it should be fine.  Plan is to MFC this to 10 soon, btw.
>>>
>>
>> Good to see that autofa has been MFC'd during my vacation 8-)
>>
>> But I found a little problem...
>>
>> When I try to access the NFS exported file-systems on an older test
>> machine (running 7.x, but that is not so relevant, it also happens
>> with other servers), with the following exports:
>>
>> $ showmount -e soekris
>> Exports list on soekris:
>> /var                               192.168.0.0
>> /usr                               192.168.0.0
>> /home                              192.168.0.0
>> /                                  192.168.0.0
>>
>> I get:
>>
>> $ ls /net/soekris
>> COPYRIGHT       dist            libexec         proc            tmp
>> bin             entropy         lost+found      rescue          usr
>> boot            etc             media           root            var
>> compat          home            mnt             sbin
>> dev             lib
>>
>> which is correct, but the next level fails:
>>
>> $ ls -l  /net/soekris/usr
>> total 0
>>
>> since /usr on soekris is definitely not empty.
>> Relevant output of mount :
>>
>> ...
>> map -hosts on /net (autofs)
>> soekris:/ on /net/soekris (nfs, nosuid, automounted)
>>
>> This is on 10.1-PRERELEASE r270922. The kernel config is GENERIC
>> minus devices I do not have and AUTOFS added. Config files
>> (/etc/auto_master, et al) are default. Mounting manually does succeed
>> (in two steps, of course).
>>
>> When trying this from Mac OS X (I am still on Snow Leopard)
>> automounting works as expected. I did not have the opportunity yet to
>> try a Linux box (also do not know whether autofs there has been eaten
>> by systemd already 8-)).
>>
>> Do I miss something, or is this a bug?
>
> It's a bug.  Or rather, a missing feature.  The problem here is that
> the "/" export "shadows" the rest.  To handle this correctly, automountd(8)
> would need to mount the "/" share, then mount autofs on "/usr" etc, and
> then call it done.  This part is easy.  The problem is: how to expire
> (automatically unmount) it?  Because of autofs mounts, the "/" share
> will always be busy, and thus won't ever get automatically unmounted.
> So, for now, we don't even try to handle this situation.
>
> I'm not sure what would the best way to solve it.
>

Maybe the same way as Mac OS X does.

On my old MacMini (Snow Leopard) I get in a quiescent state, before 
automounting anything:

/dev/disk0s2 on / (hfs, local, journaled)
devfs on /dev (devfs, local, nobrowse)
map -hosts on /net (autofs, nosuid, automounted, nobrowse)
map auto_home on /home (autofs, automounted, nobrowse)

Immediately after "ls -l /net/soekris/usr":

/dev/disk0s2 on / (hfs, local, journaled)
devfs on /dev (devfs, local, nobrowse)
map -hosts on /net (autofs, nosuid, automounted, nobrowse)
map auto_home on /home (autofs, automounted, nobrowse)
soekris:/ on /net/soekris (nfs, nodev, nosuid, automounted, nobrowse)
trigger on /net/soekris/usr (autofs, automounted, nobrowse)
trigger on /net/soekris/var (autofs, automounted, nobrowse)
trigger on /net/soekris/home (autofs, automounted, nobrowse)
soekris:/usr on /net/soekris/usr (nfs, nodev, nosuid, automounted, nobrowse)

Then, after more than 400 seconds:

/dev/disk0s2 on / (hfs, local, journaled)
devfs on /dev (devfs, local, nobrowse)
map -hosts on /net (autofs, nosuid, automounted, nobrowse)
map auto_home on /home (autofs, automounted, nobrowse)
soekris:/ on /net/soekris (nfs, nodev, nosuid, automounted, nobrowse)
trigger on /net/soekris/usr (autofs, automounted, nobrowse)
trigger on /net/soekris/var (autofs, automounted, nobrowse)
trigger on /net/soekris/home (autofs, automounted, nobrowse)

and finally after 600 seconds we are back to:

/dev/disk0s2 on / (hfs, local, journaled)
devfs on /dev (devfs, local, nobrowse)
map -hosts on /net (autofs, nosuid, automounted, nobrowse)
map auto_home on /home (autofs, automounted, nobrowse)

So triggers for the subdirectories are automounted on their automounted 
parent directory and expiration occurs in steps. BTW, I reconfigured the 
automount timeout as 300s (was 3600s) so I do not fully understand why 
the first time takes at least 400s.

If you think it is useful I can grab an older Linux box from my basement 
and try to get autofs running on it, to do the same experiment. I 
currently do not have a Solaris installation.

Kind regards,

Hans




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5408760F.2000607>