Created attachment 224112 [details]
Extend automountd, autounmountd, and autofs to understand nested automounted mount points.
(This is perhaps a duplicate of bug #195564, but I don't know whether the project prefers reopening things vs. new reports.)
I'm interested in enhancing the automounter to be able to handle nested/hierarchical keys in the -hosts map (mostly as a complement to zfs, which makes it convenient to organize data sets in nested hierarchies), so I'm attaching a working proof-of-concept implementation of the capability.
This picture shows the net result on a test machine that exports some zfs shares rooted at /t to itself:
# mount | grep /net
map -hosts on /net (autofs)
localhost:/t/a on /net/localhost/t/a (nfs, nosuid, automounted)
map -hosts on /net/localhost/t/a/b (autofs, automounted)
localhost:/t/a/b on /net/localhost/t/a/b (nfs, nosuid, automounted)
map -hosts on /net/localhost/t/a/b/c (autofs, automounted)
That is, I've added the idea of "automounted autofs" mount points. Because they're automounted, they are created dynamically by automountd and destroyed by autounmountd. Because they're autofs mounts, they eventually cause something else to get mounted.
The attachment is a tar file, here's a description of its contents:
report.txt -- this PR writeup.
notes.txt -- detailed description of the approach, limitations, future work
automountd.diff -- add the notion of automounted autofs mounts
autounmountd.diff -- teach autounmountd about unmount order dependencies.
autofs.diff -- have an automounted autofs pass getattr calls through.
These diffs apply against the releng-12.2 branch (it's what I was running when I started), but should be pretty cleanly applicable to CURRENT or HEAD, since not much has changed in the automounter.
Note that the diffs are named "logically"; in fact the first 2 diffs touch multiple files in usr.sbin/autofs, and and must be applied in the order I've mentioned them.
This set of changes is lightly tested, but does what I want it to so far under repeated, but manual, testing. That said, the approach I've taken isn't the only conceivable way to do things; it was just the shortest path I could think of from what was there to the behavior I wanted to see.
Anyhow, there's work to do before this might be merge-worthy (e.g., I haven't gotten to "automount -u" yet.) If there's an interest in incorporating this approach, I'd be very happy to iterate on this effort, ideally with some guidance/help from those who know this stuff.
Hello, and thank you! I'm really happy to see work being done on what's probably the main piece of functionality missing from our current automounter.
I like the approach you've taken. Regarding the unmounting problem (notes.txt, #1): I agree about it being the primary missing piece. I'm not sure I like the idea of recursive unmounts (or recursive anything) in the kernel. I wonder, though, using your example:
/net/foo/a (nfs, automounted)
/net/foo/a/b (autofs, automounted)
/net/foo/a/x (autofs, automounted)
/net/foo/a/b/c (nfs, automounted)
It should be technically possible (using 'umount -f') to forcibly unmount /net/foo/a despite /net/foo/a/b and its siblings still being mounted, and unmount the (now unaccessible) submounts afterwards. Thus, it might be possible to add a flag to the unmount(2) syscall to make it to fail the unmount(2) syscall with EBUSY if there are still vnodes open, except the ones with autofs submounts mounted over it?
Regarding notes.txt, #4: I think autofs(5) doesn't stop just the initial thread that triggered the mount, but also all other attempts to access the same mountpoint - the threads should "queue up" on the automountd request structure, and get unpaused after automountd signals the mount is done.
As for all the other points, I generally agree, or just have nothing to add at the moment. I've only skimmed through the source for now, but don't have any major suggestions yet apart from a fairly general ones, eg that it might make sense to use tree(3) macros, or not check for NULL before free(3).
I wonder, should we perhaps move this discussion to http://reviews.FreeBSD.org?
Thank you for taking the time to review this work! I may not have time to return to it till mid-next week, but plan to get back to it by about Wednesday the 11th. First order of business will be reworking things using the tree(3) macros, and finishing off 'automount -u'.
Happy to move the conversation to reviews.freebsd.org. I've just applied for an account there, I believe it's pending approval.