On Mon, 12 Jan 2004, Mike Waychison wrote:No. Dentries are *never* duplicated. This goes back to Viro's work on allowing a filesystem to be mounted in multiple locations. See http://kt.zork.net/kernel-traffic/kt20000424_64.html#9 .
And I have another question concerning namespaces.This is the reason I went with using distinct filesystems to perform the
Given that there may be several namespaces, each of which may or may not have a trigger on this dentry, is there some sort of list of triggers?
How do the triggers know who owns them?
triggers. If we use follow_link logic, we will have a reference to the
respective vfsmount. Dentry's themselves know nothing about the
triggers, as the triggers just look like a mounted filesystem. The
vfsmount information has enough information for autofs to call a
userspace agent through hotplug and have userspace handle the mount. In
effect, there is no daemon so nobody 'owns' a trigger in the same sense
as with autofs3/4.
I'm not familiar with the follow_link mechanism (no prob. I'll pick it up as I go).
Correct me if I'm wrong but, the only thing that I can see that is
duplicated in cloning a namespace is the root dentry. The rest of the
dentries on the system remain the same. The increase in complexity to the
VFS to change this would be prohibitive.
What is duplicated is the current->namespace tree of vfsmounts. After this is done, current->fs vfsmount members are updated to point to their cloned counterparts.
If triggers in the vfsmount struct are done, then there will be no need to handle lookups or revalidates. In fact, triggers in the vfsmount struct will not help at all for indirect maps.I see we want the triggers in the vfsmount struct. Is this a good idea? The vfsmount struct has always been difficult to get hold of during lookup and revalidate for me (someone like to help here).
I don't see what you want here. If you have hundreds of users logged into the same machine, you *will* have hundreds of entries in the mount-table.
Also, something needs to be done about mount table noise. Several hundred
entries is very bad from an administration viewpoint.
Except for the cross namespace issues, which I'm still digesting, I can'tMy proposal uses filesystems for all automount mechanism *except* expiry. I see expiry as a VFS service, and strongly believe that this is where it belongs.
see why your design can't be done entirely as a filesystem using dentries
instead of vfsmount, including expirey. Perhaps you could reinterate a few
of the reasons for this.
-- 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
