lkml.org 
[lkml]   [2003]   [Jun]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH] VFS autmounter support
    Date
    From

    > This seems a bit heavyweight; although some VFS support is needed for
    > a complex filesystem, effectively doing it all in the kernel (#3)
    > seems a bit... excessive.

    One of the problems I have to deal with is namespaces. This means I can't just
    have an automounter running in userspace that's passed requests to mount
    things as it might not be able to access the target namespace.

    Doing it this way means that I don't need to care which namespace the
    automount needs to take effect in. I can just return a vfsmount to the VFS (as
    acquired from do_kern_mount()) and let that paste it into the right place.

    Furthermore, for AFS at least, it's a lot less excessive than, say, calling
    back into userspace.

    > At least #2 can be done with existing means using follow_link.

    How? I want to be able to mount on the location in question (so it has to be a
    directory), but I don't want "ls -l" to cause it to mount (otherwise
    accidentally doing that or tab expansion if /afs, say, will take ages).

    Maybe you mean construct a symlink that points to somewhere I can actually
    mount the filesystem? If so, that too can suffer from namespace problems.

    Whatever happens, stat() must _not_ cause the automount point to mount.

    > I think using a revalidation pointer like dentries might be a better
    > way to do #4/#5, although using the existing one in the dentries is
    > probably better.

    Do you mean dispose of the expired mount point when it's next revalidated? If
    so, surely you _don't_ want to do it then, as that's normally a prelude to
    reusing it.

    Or do you mean do it actually inside dentry->d_op->d_revalidate()? But you
    can't do it there because you don't know what vfsmount you are dealing with.

    > #1 isn't really clear to me what you're going for, but it seems to be
    > to duplicate bookkeeping.

    Duplicate of what bookkeeping?

    The fact that the operation is provided indicates that a dentry is an
    automount point, and as such should be handled specially by path-walk. All the
    logic to link the new vfsmount into the filesystem topology can be handled
    easily by the VFS at that point because all the details are to hand.

    > I also don't see how this solves the biggest problems with complex
    > automounts, which are:
    >
    > a) how to guarantee that a large mount tree can be safely destroyed;

    What do you mean by safely? I check that the usage count on vfsmount
    structures is 1 under lock just before unlinking it - thereby making sure that
    no one has a file open on it, no process has it as its root or cwd, and that
    nothing is mounted upon it.

    Also, I do the actual unmounting from process context by walking the
    namespace's extant mount list, rather than directly nominating a vfsmount for
    removal.

    One drawback is that - taking AFS as an example - doing a umount of /afs won't
    work until all the subtrees have either been manually unmounted or have
    expired (though I can make umount capable of handling this).

    > b) how to detect partial unmounts.

    What do you mean by a partial unmount?

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

    \
     
     \ /
      Last update: 2005-03-22 13:36    [W:0.024 / U:62.584 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site