autofs-5 supports recursive mounts, very handy for bind or loop mounts when you first have to mount the underlying filesystem. What isn't obvious (it took me a code read to work this out) is that this is incompatible with "mount locking". Mount locking refers to locking intended to prevent corruption to /etc/mtab in the face of concurrent mount attempts. It seems the implementation of this is messy, spread across a number of components, and has been difficult to get right. Eg. see http://comments.gmane.org/gmane.linux.utilities.util-linux-ng/2 Despite some googling, I haven't been able to work out what the current status is. Anyway, the lowdown is that at the moment to have recursive mounts, you need to configure autofs with --disable-mount-locking. I think this is worth having a USE flag for. Most desktop users won't be doing lots of concurrent mounting and won't encounter a problem, and recursive automounts are very useful. Reproducible: Always Steps to Reproduce: Here's a sample autofs config that demonstrates a recursive mount: $ cat /etc/autofs/auto.direct /home/library/movies -fstype=bind :/mnt/local/lib1/movies /home/library/tv -fstype=bind :/mnt/local/lib1/tv $ cat /etc/autofs/auto.local # LABEL=xxxx will be mounted at xxxx * -fstype=auto LABEL=& $ cat /etc/autofs/auto.master /mnt/local /etc/autofs/auto.local /- /etc/autofs/auto.direct If autofs is configured with --disable-mount-locking, accessing /home/library/movies will cause autofs to first "mount LABEL=lib1 /mnt/local/lib1" and then "mount --bind /mnt/local/lib1/movies /home/library/movies". Without --disable-mount-locking (the default) autofs will not recurse, try the bind mount, and fail.
Thanks for the report. I understand that this feature can be useful. Before deciding whether this option will be supported officially, I would like to wait for a reply of upstream's Ian Kent on autofs's mailing list where I already read your inquiry about the status of mtab locking. So I would like to ask you to be a bit patient. Of course, you could implement this feature in your local overlay and test it. If you do so and encounter problems, please let us know in this bug. Thanks.
Ah, that's interesting... I didn't realise my message had gotten through to the list; didn't show up on any of the archives I looked at. I was going to wait for a reply myself and post a link before filing the report; but I gave up because I thought the list wasn't talking to me. Anyway, --disable-mount-locking works fine for me, but I'm just doing bind mounts to filesystems on a couple of external USB drives. Not exactly sure how to create conditions that would be expected to cause issues; anyway I agree, wait for replies, hopefully at least get some decent info for a warning in the ebuild.
After upstream responded positively on their mailing list, I will have a look at including this feature as soon as I find time to work on this. As reference, I put upstream's response from Ian Kent here: On Tue, 2011-12-20 at 14:31 +1100, Gerard Neil wrote: > Hello, > > I just spent a few hours getting recursive bind mounts working on a > gentoo system. It took a code read for me to realise that recursive > mounts and mtab locking are mutually exclusive; ie. if I want > recursive mounts, I have to pass --disable-mount-locking to configure > when building autofs. Yes, that's right. > > Currently the gentoo ebuild doesn't allow this as an option; I'd like > to make this friendlier for people in the future, maybe by adding a > USE flag. > > But before that, I'd like to know the current status of the mtab > locking issue. From a bit of googling, it looks like the idea was to > move the mtab locking into libmount, but it's one of those messy > things that's hard to pin down and I haven't been able to work out > where this work is at. My understanding is that without > --disable-mount-locking, it is possible to corrupt /etc/mtab, leading > to weirdness when userspace utilities don't find what's expected in > that file. The likelyhood of such a corruption goes up if a lot of > filesystems are being automounted. Is this still correct? Is this > fixed in later versions of util-linux-ng? While --disable-mount-locking isn't enabled by default it probably should be used rather than not, but it's a pain to change and possibly would make it more likely I get bug reports about mtab. I have used the --disable-mount-locking in builds for a long time and I haven't heard of problems with mtab corruption for quite a while but it still seems to come up from time to time. OTOH autofs hasn't been dependent on mtab being correct for a while now (provided you are using the new ioctl interface, ie /dev/autofs) so it doesn't really care about it. IOW the problem really belongs to someone else now.
Just to give a short progress update: I am currently working on an ebuild containing newest upstream patches. I will include this feature in this ebuild as well. So, now is the time to bikeshed the new use flag: I propose 'recursive-mount', which is quite long. So if anyone wants it shorter, please make a suggestion :) Description I want to put into metadata.xml: """ Allows to use recursive mount configurations, e.g. bind mount a mount point that needs to be automounted as well. Enabling this option will disable mtab locking, which might lead to a mtab corruption with concurrent mounting. Use on your own risk. """
To my thinking, the USE flag should be called mount-locking, to align with the underlying autofs option. That's what the USE flag does, giving it another name based on a side-effect just introduces confusion. My preference would be to *disable* mount-locking by default. In light of Ian's comments (and given that he himself has been using --disable-mount-locking) it looks like the chances of people running into issues are pretty slim. The USE flag description would be something like: Enable locking to prevent corruption of /etc/mtab in the presence of concurrent auto-mounting. If enabled, recursive auto-mounting (eg. using autofs to bind or loop mount a filesystem which is itself auto-mounted) is not possible.
Also I would like the flag coloured NavajoWhite with CornflowerBlue trim. Thanks.
This is now available with autofs-5.0.7.
