Date: Fri, 30 Apr 2021 20:04:13 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 255061] [PATCH] Proof of concept nested mounts for automounter -hosts map Message-ID: <bug-255061-227-69fQASnW7y@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-255061-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255061 Edward Tomasz Napierala <trasz@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |trasz@FreeBSD.org --- Comment #1 from Edward Tomasz Napierala <trasz@FreeBSD.org> --- 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 (autofs) /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? Thanks again! -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-255061-227-69fQASnW7y>