Hi. Beware the recent idea of multiply-mounted block devices. It might
cause wierdness to have a device of union-mount-layer type unioned at two
places in the filesystem. Gak.
On Wed, Jun 07, 2000 at 12:51:36AM -0400, Alexander Viro wrote:
> A) suppose we have a bunch of filesystems union-mounted on
> /foo/bar. We do chdir("/foo/bar"), what should become busy? Variants:
> mountpoint, first element, last element, all of them.
> B) after the action in (A) we add another filesystem to the set.
> Again, what should happen to the busy/not busy status of the components?
All union-mounts that we don't pass-through, and the obvious real mount,
should be busy.
> C) we start with the normal mount and union-mount something else.
> Question: what is the desired result (almost definitely the set of old and
> new mounted stuff) and who should become busy?
I'd love to be able to delete things, but that's quite a challenge.
> D) In the cases above, what do we want to get from stat(2)?
stat() of what? The mount-point directory should return the upper layer,
IMO, as should statfs() for anything above it.
> E) What do we want to do if we do normal mount atop of the
[...] (basically, "if we already have mtab
> entry for this mountpoint and mount succeeds - discard the old one").
This might be done in kernel-space, if implemented. Still I don't think
we should unmount anything implicitly. Even now, if we have '/' and
'/foo/bar' mounted, and we mount a new device atop '/foo', we don't
unmount '/foo/bar' -- for plenty of good reasons, the biggest of which is
that a process may still have a descriptor inside '/foo/bar/...' open.
- chad
-- Chad Miller <cmiller@surfsouth.com> URL: http://web.chad.org/ (GPG) "Any technology distinguishable from magic is insufficiently advanced". First corollary to Clarke's Third Law (Jargon File, v4.2.0, 'magic')- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:29 EST