Mike Waychison wrote:Yes, but they shouldn't occur due to normal operation of the system. Yes, the administrator can manually prune things away, yet the remaining bits should still be able to expire atomically.
This is an interesting approach to killing off a mountpoint. However, the problem in question is not the destruction of the mountpoints, but rather being able to check_activity_of_a_hierarchy_of_mountpoints/unmount_them_together atomically. This cannot be done cleanly in userspace even when given an interface to do the check, someone can race in before userspace initiates the unmounts. The alternative is to have userspace detach the hierarchy of mountpoints using the '-l' option to umount(8), but then we may still unneccesarily unmount the filesystem will someone is in it. I think that both HPA and I agree that this capability is needed in order to support lazy mounting of multimounts properly. The issue that remains is *how* to do it.
I would argue even stronger: allowing the administrator to umount
directories manually is a hard requirement. This means that partial
hierarchies *will* occur. Thus, relying on the hierarchy being
atomically destructed in inherently broken.
On the other end of the spectrum is the situation where if I had accessed my homedir, /home/mikew, and then I manually mounted something in /home/mikew/mnt as root in another window, /home/mikew should _not_ expire. /home/mikew/mnt is not managed by the automounter, so it shouldn't be expired by it either.
Yes, and this policy in my proposal is handled by the automount useragent. The system is constructed such that any waiting processes are released when the useragent dies off. If userspace wanted to let people in before it finished construction, it would fork and exit in the parent process.This means that constructing the hierarchy with direct-mount automount triggers in between the filesystems is mandatory; you get lazy mounting for free, then -- it's a userspace policy decision whether or not to release the waiting processes before the hierarchy is complete or not.
But it doesn't work as a daemon when you have namespaces created left and right. It *would maybe* work as a cron job, if cron was namespace aware.Now, once you recognize that the administrator needs to be able to do umounts, expiry in userspace becomes quite trivial, since expiry is inherently probabilistic: it can simply mimic an administrator preening the trees, and if it fails, stop (or re-mount the submounts, policy decision.) Having a simple kernel-assist to avoid needless umount operations is a good thing if (and only if!) it's cheap, but it doesn't have to be foolproof.
??Again, the atomicity constraint that umounting a filesystem needs to destroy the mount traps above it derives from the need to cleanly deal with nonatomic destruction.
Off the top of my head, I don't see any issues, but you are right in that something may creep up.The time required to unmount something is constant if we detach the mountpoint using a lazy umount.
You probably don't want to do that -- you could end up with some really odd timing-related bugs if you then re-mount the filesystem. It's also unnecessary, since expiry is not a triggered event and therefore doesn't keep anything that needs to happen from happening.
-- Mike Waychison Sun Microsystems, Inc. 1 (650) 352-5299 voice 1 (416) 202-8336 voice mailto: [EMAIL PROTECTED] http://www.sun.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pgp00000.pgp
Description: PGP signature_______________________________________________ autofs mailing list [EMAIL PROTECTED] http://linux.kernel.org/mailman/listinfo/autofs
