Re: [RFC PATCH] file as directory

Interesting... How do you deal with mount propagation and things like
mount --move?

Moving (or doing other mount operations on) an ancestor shouldn't be a
problem. Moving this mount itself is not allowed, and neither is
doing bind or pivot_root. Maybe bind could be allowed...

Eh... Arbitrary limitations are fun, aren't they?

But these mounts _are_ special. There is really no point in moving or
pivoting them.

When doing recursive bind on ancestor, these mounts are skipped.

What about clone copying your namespace?

In that case they are cloned, but only those survive which have refs
in the new namespace.

What about MNT_SLAVE stuff being set up prior to that lookup?

These mounts are not propagated. Or at least I hope so. Propagation
stuff is a bit too complicated for my poor little brain.

More interesting question: should independent lookups of that sucker
on different paths end up with the same superblock (and vfsmount for
each) or should we get fully independent mount on each? The latter
would be interesting wrt cache coherency...

I think they should be the same superblock, same dentry. What would
be the advantage of doing otherwise?

As for unlink... How do you deal with having that thing
mounted, mounting something _under_ it (so that vfsmount would be kept
busy) and then unlinking that sucker?

Yeah, that's a good point. Current patch doesn't deal with that.
Simplest solution could be to disallow submounting these. Don't think
it makes much sense anyway.

Arbitrary limitations... (and that's where revalidate horrors come in, BTW).
BTW^2: what if fs mounted that way will happen to have such node itself?

I think doing this recursively should be allowed. "Releasing last ref
cleans up the mess" should work in that case.

I'm not saying that it's unfeasible or won't lead to interesting things,
but it really needs semantics done right...

Agreed :)

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

Relevant Pages

  • [PATCH] intrinsic automount and mountpoint degradation support [try #2]
    ... When a filesystem wants to create an expirable mount, ... When something using a vfsmount finishes dealing with it, ... An expiration facility is also provided to userspace: ... mountpoint hasn't been used since the last request and isn't in use now. ...
    (Linux-Kernel)
  • [RFC PATCH 5/10] vfs: shared subtree aware bind mounts
    ... Patch that help bind/rbind a mount tree. ... static void attach_mnt(struct vfsmount *mnt, ... +static inline int tree_contains_propagation ...
    (Linux-Kernel)
  • [RFC PATCH] file as directory
    ... When a non-directory object is accessed without a trailing slash, ... If there's no trailing slash is after the file name, the mount ... * Follows mounts on the given struct path. ... * reference is held for the supplied vfsmount. ...
    (Linux-Kernel)
  • [RFC PATCH 2/10] vfs: make mounts shared/slave/private
    ... A shared mount can be bind-mount to some mountpoint. ... +static int do_change_type ... +static void make_slave_of(struct vfsmount *mnt, ... +static inline void set_mnt_private ...
    (Linux-Kernel)
  • Re: [VFS-RFC] autofs4 and bind, rbind and move mount requests
    ... The result is very similar to move mount. ... > I don't think it should because autofs needs be true to the mount maps ... do_add_mountcall (which places the vfsmount on the expiry list), ... If you just want to disable bind, ...
    (Linux-Kernel)