From: Mike Waychison <Michael.Waychison@Sun.COM>
To: Ram <linuxram@us.ibm.com>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
Al Viro <viro@parcelfarce.linux.theplanet.co.uk>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] shared subtrees
Date: Tue, 25 Jan 2005 16:47:04 -0500 [thread overview]
Message-ID: <41F6BE58.50208@sun.com> (raw)
In-Reply-To: <1106687232.3298.37.camel@localhost>
-----BEGIN PGP SIGNED MESSAGE-----
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:
>>
>>http://www.fieldses.org/~bfields/kernel/viro_mount_propagation.txt
>
>
>
> 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.
So:
- - /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 majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
- --
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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB9r5YdQs4kOxk3/MRApT3AJ9xxpdacU0mp8IvsY395MDtEktJ+wCeOvRT
/g7qXO9nGxMT/iFAZoUO8F4=
=9D2G
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2005-01-25 21:53 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-13 22:18 [RFC] shared subtrees Al Viro
2005-01-13 23:30 ` Mike Waychison
2005-01-14 0:19 ` Al Viro
2005-01-14 1:11 ` Erez Zadok
2005-01-14 1:38 ` Al Viro
2005-01-16 0:46 ` J. Bruce Fields
2005-01-16 0:51 ` Al Viro
2005-01-16 16:02 ` J. Bruce Fields
2005-01-16 18:06 ` Al Viro
2005-01-16 18:42 ` J. Bruce Fields
2005-01-17 6:11 ` Al Viro
2005-01-17 17:32 ` J. Bruce Fields
2005-01-25 21:07 ` Ram
2005-01-25 21:47 ` Mike Waychison [this message]
2005-01-25 21:55 ` J. Bruce Fields
2005-01-25 23:56 ` Mike Waychison
2005-01-25 22:02 ` Ram
2005-02-01 23:37 ` J. Bruce Fields
2005-02-02 1:37 ` J. Bruce Fields
2005-02-01 23:21 ` J. Bruce Fields
2005-02-02 18:36 ` Ram
2005-02-02 19:45 ` Mike Waychison
2005-02-02 20:33 ` Ram
2005-02-02 21:08 ` Mike Waychison
2005-02-02 21:25 ` J. Bruce Fields
2005-02-02 21:33 ` Mike Waychison
2005-02-02 21:48 ` J. Bruce Fields
2005-04-05 9:37 ` Ram
2005-01-17 18:31 ` Mike Waychison
2005-01-17 19:00 ` J. Bruce Fields
2005-01-17 19:30 ` Mike Waychison
2005-01-17 19:32 ` J. Bruce Fields
2005-01-17 20:11 ` Mike Waychison
2005-01-17 20:39 ` Al Viro
2005-01-18 19:44 ` Mike Waychison
2005-01-17 21:21 ` J. Bruce Fields
2005-01-28 22:31 ` Mike Waychison
2005-01-29 4:40 ` raven
2005-01-31 17:19 ` Mike Waychison
2005-02-01 1:31 ` Ian Kent
2005-02-01 2:28 ` Ram
2005-02-01 7:02 ` Mike Waychison
2005-02-01 19:27 ` Ram
2005-02-01 21:15 ` Mike Waychison
2005-02-01 23:33 ` Ram
2005-02-02 2:10 ` J. Bruce Fields
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41F6BE58.50208@sun.com \
--to=michael.waychison@sun.com \
--cc=bfields@fieldses.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxram@us.ibm.com \
--cc=viro@parcelfarce.linux.theplanet.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.