Re: [RFC PATCH 1/8] share/private/slave a subtree

From: Miklos Szeredi <miklos@szeredi.hu>
To: linuxram@us.ibm.com
Cc: miklos@szeredi.hu, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org,
	viro@parcelfarce.linux.theplanet.co.uk, akpm@osdl.org,
	mike@waychison.com, bfields@fieldses.org
Subject: Re: [RFC PATCH 1/8] share/private/slave a subtree
Date: Fri, 08 Jul 2005 21:49:04 +0200	[thread overview]
Message-ID: <E1DqyqO-00057C-00@dorka.pomaz.szeredi.hu> (raw)
In-Reply-To: <1120845120.30164.139.camel@localhost> (message from Ram on Fri, 08 Jul 2005 10:52:00 -0700)

> The reason why I implemented that way, is to less confuse the user and
> provide more flexibility. With my implementation, we have the ability
> to share any part of the tree, without bothering if it is a mountpoint
> or not. The side effect of this operation is, it ends up creating 
> a vfsmount if the dentry is not a mountpoint.
> 
> so when a user says
>       mount --make-shared /tmp/abc
> the tree under /tmp/abc becomes shared. 
> With your suggestion either the user will get -EINVAL or the tree
> under / will become shared. The second behavior will be really
> confusing.

You are right.

> I am ok with -EINVAL. 

I think it should be this then.  These operations are similar to a
remount (they don't actually mount something, just change some
property of a mount).  Remount returns -EINVAL if not performed on the
root of a mount.

> Also there is another reason why I used this behavior. Lets say /mnt
> is a mountpoint and Say a user does
> 		mount make-shared /mnt 
> 
> and then does 
>                 mount --bind /mnt/abc  /mnt1
> 
> NOTE: we need propogation to be set up between /mnt/abc and /mnt1 and
> propogation can only be set up for vfsmounts.  In this case /mnt/abc 
> is not a mountpoint. I have two choices, either return -EINVAL
> or create a vfsmount at that point. But -EINVAL is not consistent
> with standard --bind behavior. So I chose the later behavior.
> 
> Now that we anyway need this behavior while doing bind mounts from
> shared trees, I kept the same behavior for --make-shared.

Well, the mount program can easily implement this behavior if wanted,
just by doing the 'bind dir dir' and then doing 'make-shared dir'.

The other way round (disabling the automatic 'bind dir dir') is much
more difficult.

> > Some notes (maybe outside the code) explaining the mechanism of the
> > propagations would be nice.  Without these it's hard to understand the
> > design decisions behind such an implementation.
> 
> Ok. I will make a small writeup on the mechanism.

That will help, thanks.

Miklos