Re: [MooseFS-Users] Caution re: MooseFS mounting from automount in CentOS 7

[Aleksander W. <ale...@mo...>]

Hi Steve,
Thank you for all this information.

Please update us in case of any problems with systemd automount option.
 
Best regards
Aleksander Wieliczko
Technical Support Engineer
MooseFS.com <moosefs.com>

On 12/13/2016 02:58 PM, Wilson, Steven M wrote:
>
> Hi Aleksander,
>
>
> I started using autofs because I wanted to only mount MooseFS file
> systems as they were needed and then have them unmounted when they are
> no longer in use.  That helps free up some CPU and memory resources
> when file systems are not in use (not much, though) but it also helps
> make it easier to update the MooseFS client to a newer version.  We've
> used autofs for some NFS mounts for many years (and amd before
> that...) so it was only natural to incorporate MooseFS into our autofs
> environment.
>
>
> Thanks for the pointer to systemd automount.  I didn't realize that it
> also supported an unmount option after a pre-determined idle timeout.
>  I'll look into perhaps using that in the future.
>
>
> Best regards,
>
> Steve
>
>
> ------------------------------------------------------------------------
> *From:* Aleksander Wieliczko <ale...@mo...>
> *Sent:* Tuesday, December 13, 2016 1:54 AM
> *To:* Wilson, Steven M; MooseFS-Users
> *Subject:* Re: [MooseFS-Users] Caution re: MooseFS mounting from
> automount in CentOS 7
>  
> Hi Steve,
> Thank you for all this information.
> Basically we never used MooseFS client with autofs.
>
> Can you tell us what is the real goal of usingautofs with mfsmount?
> Is the mfsmount entry in fstab not sufficient in your case?
>
> More information about fstab you can find on mfsmount man page.
> https://moosefs.com/manpages/mfsmount.html
>
> By the way, you can try to use native systemd x-systemd.automount feature.
>
> Best regards
> Aleksander Wieliczko
> Technical Support Engineer
> MooseFS.com <moosefs.com>
>
>
> On 12/12/2016 07:01 PM, Wilson, Steven M wrote:
>>
>> Hi,
>>
>>
>> I ran into an interesting problem on a small subset of our systems
>> that were running CentOS 7.  I've begun using autofs for mounting
>> MooseFS filesystems on an as-needed basis and I found that our users
>> were unable to mount and use any MooseFS filesystems from CentOS 7
>> workstations.  ps showed the following:
>>
>> ​    root     12550  1.9  1.0 520304 82260 ?        S<sl 12:35   0:00
>> /sbin/mount.moosefs sb-data:/apps /net/apps -n -o rw,mfsbind=10.145.7.31
>> Note the "-n" option which is an mfsmount option that will "omit
>> default mount options (-o allow_other)".  This was obviously the
>> cause of my problem but where was it coming from?  My automount map
>> file for this filesystem is the following with no explicit "-n" option:
>>     apps \
>>         -fstype=moosefs,mfsbind=10.145.7.31 \
>>         sb-data:/apps
>>
>> Turning on debug logging for automount, I get this message in the
>> logs:    
>>     Dec 12 11:21:59 gateway automount[7146]: spawn_umount: mtab link
>> detected, passing -n to mount
>>
>> So, if /etc/mtab is a link the automount will pass a "-n" option to
>> the mount command.  The general "-n" option for mount is to "mount
>> without writing in /etc/mtab".  This general option gets passed down
>> to mount.moosefs which interprets it quite differently!
>>
>> An easy, but not so elegant, work-around is to change the map file
>> entry to include an "allow_other" option like this:
>>     apps \
>>         -fstype=moosefs,allow_other,mfsbind=10.145.7.31 \
>>         sb-data:/apps
>>
>> I don't understand why this only causes problems with CentOS 7 and
>> not on my Ubuntu 16.04 installations which also have /etc/mtab set up
>> as a symbolic link to /proc/self/mounts.  Ubuntu is using a different
>> version of automount (5.1.1 compared to 5.0.7) but it looks like it's
>> still checking for the mtab symbolic link:
>>
>>    root@otter:~# strings /usr/sbin/automount | grep 'mtab link detected'
>>     %s: mtab link detected, passing -n to mount
>>
>> Hopefully this will prove helpful to anyone else who might run into
>> the same issue.  And if someone has a better way to deal with it, let
>> me know.
>>
>>
>> Regards,
>>
>> Steve
>>
>