Date:	Thu, 27 Jul 2000 13:40:10 -0400 (EDT)
From:	Alexander Viro <viro@math.psu.edu>
To:	Andries Brouwer <aeb@veritas.com>
Subject: Re: multimounting cdroms ???



On Thu, 27 Jul 2000, Andries Brouwer wrote:

> On Wed, Jul 26, 2000 at 08:50:28PM -0400, Alexander Viro wrote:
> 
> > But yes, this thing with stacking them over the same point needs to be fixed.
> > IMO "replacement" semantics is the right way
> 
> I don't like replacement. The number of mounts should equal
> the number of umounts.
> Just return EBUSY if mount is called with the same filesystem on
> the same mount point (without the -o remount flag).
> All else is allowed.

That's certainly possible. However, consider the following: suppose we've
done union-mounts. We have foo, bar and baz union-mounted on /quux. We
mount frob on /quux. Where should it go? Notice that considering union as
a stack _will_ _not_ _work_. Unlike 4.4 we may have the same fs mounted in
many places and modifying dentries is simply not an option - the same fs
may be a member of many unions.

What I'm really interested in is a consistent semantics for _that_. If
anyone can come up with such a beast - I'll be glad to do it. Otherwise it
will probably boil down to refusing stacked mounts unless you pass a flag.
Requirements:
	a) normal mount should be a boundary case of union - it's a union
consisting of 1 element.
	b) we should be able to have the same fs in many unions.
	c) we should be able to add new elements both to beginning and end
of existing union.
	d) transparent mount == union-mount of (mounted, loopback to
mountpoint) over mountpoint.

BTW, umount interface for unions is not a problem, we _can_ identify
elements of union and do selective umount.

	I'm asking about semantics, not implementation, but implementation
considerations along with (b) exclude union-as-a-stack semantics. For
reference, existing variants look so:
	4.4BSD - union-as-a-stack, no way to mount the same fs many times,
single namespace.
	Plan 9 - mountpoint -> list of members, normal mount == replace,
union-mount == add, umount is always possible, garbage-collect mounts when
the last process using the namespace dies.

	Both variants have sucking points: 4.4BSD way effectively prevents
per-process namespaces (aside of the general state of their VFS - it's a
living horror). Plan 9 idea of umount has, erm, unpleasant side effects -
GC on the exit of last process in namespace group _somewhat_ makes life
bearable, but it's heavily biased towards their usual setup when all
filesystems with persistent state live on a separate box. There are _some_
merits of that approach for our usual setups (currently stuck /foo/bar/baz
upon shutdown means no umount for root for no good reason), but I really
doubt that overall it's a good idea.

	Having a way to do per-process namespaces combined with unions is
a Good Thing(tm) for a lot of reasons and if it can be done with clear
semantics - IMNSHO it should be done. Currently the _only_ serious holding
point for that is a clear semantics for unions. It's not going into 2.4
due to the changes needed in ->readdir() prototype (needed for any form of
unions, BTW), but having it very early in 2.5 is possible.


-
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/