-----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 [EMAIL PROTECTED] > 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----- - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
