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

[Wilson, S. M <st...@pu...>]

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