H. Peter Anvin wrote: >Mike Waychison wrote: > > >>>Special vfsmount mounted somewhere; has no superblock associated with it; >>>attempt to step on it triggers event; normal result of that event is to >>>get a normal mount on top of it, at which point usual chaining logics >>>will make sure that we don't see the trap until it's uncovered by removal >>>of covering filesystem. Trap (and everything mounted on it, etc.) can >>>be removed by normal lazy umount. >>> >>>Basically, it's a single-point analog of autofs done entirely in VFS. >>>The job of automounter is to maintain the traps and react to events. >>> >>> >>> >>Is there any clear advantage to doing this in the VFS other than saving >>a superblock and a dentry/inode pair or two? >> >>I remember talking to you about this, and I seem to recall that these >>mount traps would probably communicate using a struct file, so a >>trap-user would somehow receive events about when the trap was set >>off. Will this communication model continue to work within a cloned >>namespace? What happens if the trap-client closes the file? >> >> >> > >The biggest issue is to ensure that the appropriate atomicity guarantees >can be maintained. In particular, it must be possible to umount the >underlying filesystem and all mount traps on top of it atomically. >Anything less will result in race conditions. > > -hpa > > > Unless I'm missing something, implementing this as a seperate filesystem type still has the appropriate atomicity guarantees as long as the VFS support complex expiry, whereby userspace would tag submounts as being part of the overall expiry for a base mountpoint. -- Mike Waychison Sun Microsystems, Inc. 1 (650) 352-5299 voice 1 (416) 202-8336 voice mailto: Michael.Waychison@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. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~