Re: [autofs] [RFC] Towards a Modern Autofs

[Mike Waychison <Michael.Waychison _at_ xxxxxxx>]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig90F0E425FCCF33089537B762
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

H. Peter Anvin wrote:

>Mike Waychison wrote:
>  
>
>>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.
>  
>
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.

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.

>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.
>
>  
>
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.

>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.
>
>  
>
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.

>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.
>
>  
>
??

>>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.
>
>  
>
Off the top of my head, I don't see any issues, but you are right in 
that something may creep up. 

-- 
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice
mailto: Michael.Waychison _at_ Sun.COM
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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 


--------------enig90F0E425FCCF33089537B762
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iD8DBQE//yCIdQs4kOxk3/MRAnxvAJ4yYiUDtlN5Du7XBf+vxSdwhzP6wACgniVK
QTa+HmcaXF6gXcIpr+C+TsI=
=q4pi
-----END PGP SIGNATURE-----

--------------enig90F0E425FCCF33089537B762--

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo _at_ vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/