[lkml]   [2005]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] shared subtrees
Hash: SHA1

Hi Ram,

I can't speak for Al, but the following is how I understand it:

Ram wrote:
> On Mon, 2005-01-17 at 09:32, J. Bruce Fields wrote:
>>On Mon, Jan 17, 2005 at 06:11:50AM +0000, Al Viro wrote:
>>>No - I have been missing a typo. Make that "if mountpoint of what we
>>>are moving...".
>>OK, got it, so the point is that its not clear how you'd propagate the
>>removal of the subtree from the vfsmount of the source mountpoint.
>>By the way, I wrote up some notes this weekend in an attempt to explain
>>the shared subtrees RFC to myself. They may or may not be helpful to
>>anyone else:
> Question 1:
> If there exists a private subtree in a larger shared subtree, what
> happens when the larger shared subtree is rbound to some other place?
> Is a new private subtree created in the new larger shared subtree? or
> will that be pruned out in the new larger subtree?
> Concrete example:
> mount <device1> /tmp/mnt1
> mount <device2> /tmp/mnt1/mnt1.1
> mount <device3> /tmp/mnt1/mnt1.1/mnt1.1.1
> make --make-shared /tmp/mnt1
> mount --make-private /tmp/mnt1/mnt1.1

Not needed, see below:

> make --rbind /tmp/mnt1 /tmp/mnt2
> Question: will I see the mount at /tmp/mnt2/mnt1.1/mnt1.1.1 ?
> My guess is since /tmp/mnt1/mnt1.1 is private that subtree
> should not be even seen under /tmp/mnt2/mnt1.1 , Is that
> the case? Or does the subtree get mirrored in /tmp/mnt2/mnt1.1;
> however propogation is not set between the vfsstruct of
> /mnt/mnt1/mnt1.1 and /mnt/mnt2/mnt1.1 ?
> I believe its the former case.

Although Al hasn't explicitly defined the semantics for mount
- --make-shared, I think the idea is that 'only' that mountpoint becomes
tagged as shared (becomes a member of a p-node of size 1). The
- --make-shared / --make-private / --make-slave should probably all be
non-recursive actions.

/tmp/mnt1/mnt1.1 and /tmp/mnt1/mnt1.1/mnt1.1.1 will remain private.

The --rbind is described as simply walking the vfsmount tree rooted at
the argument and performing --bind.


- - /tmp/mnt2 becomes a peer of /tmp/mnt1, because /tmp/mnt1 was in a
non-empty p-node.
- - /tmp/mnt2/mnt1.1 becomes a copy of /tmp/mnt1/mnt1.1 because the latter
was not in a p-node.
- - /tmp/mnt2/mnt1.1.1 becomes a copy of /tmp/mnt1/mnt1.1/mnt1.1.1 because
the latter was not in a p-node.

Only new mounts placed on top of /tmp/mnt1 and /tmp/mmnt2 will get
propagated back and forth.

> Question 2:
> When a mount gets propogated to a slave, but the slave
> has mounted something else at the same place, and hence
> that mount point is masked, what will happen?
> Concrete example:
> mount <device1> /tmp/mnt1
> mkdir -p /tmp/mnt1/a/b
> mount --rbind /tmp/mnt1 /tmp/mnt2
> mount --make-slave /tmp/mnt2

EINVAL. You should only be able to demote a mountpoint to a slave if it
was part of a p-node (shared).

> mount <device2> /tmp/mnt2/a
> rm -f /tmp/mnt2/a/*
> what happens when a mount is attempted on /tmp/mnt1/a/b?
> will that be reflected in /tmp/mnt2/a ?
> I believe the answer is 'no', because that part of the subtree
> in /tmp/mnt2 no more mirrors its parent subtree.
> RP
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to
> More majordomo info at

- --
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice

NOTICE: The opinions expressed in this email are held by me,
and may not represent the views of Sun Microsystems, Inc.
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:09    [W:0.056 / U:7.240 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site