lkml.org 
[lkml]   [2005]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] shared subtrees
    -----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-----
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:09    [W:0.029 / U:30.264 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site