Re: [RFC] shared subtrees

[Mike Waychison]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ram wrote:
> On Wed, 2005-02-02 at 11:45, Mike Waychison wrote:
> 
> Ram wrote:
> 
>>On Tue, 2005-02-01 at 15:21, J. Bruce Fields wrote:
> 
> 
>>>On Tue, Jan 25, 2005 at 01:07:12PM -0800, Ram wrote:
> 
> 
>>>>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?
> 
>>>"mount --rbind" will always do at least all the mounts that it did
>>>before the introduction of shared subtrees--so certainly it will copy
>>>private subtrees along with shared ones.  (Since subtrees are private by
>>>default, anything else would make --rbind do nothing by default.) My
>>>understanding of Viro's RFC is that the new subtree will have no
>>>connection with the preexisting private subtree (we want private
>>>subtrees to stay private), but that the new copy will end up with
>>>whatever propagation the target of the "mount --rbind" had.  (So the
>>>addition of the copy of the private subtree to the target vfsmount will
>>>be replicated on any vfsmount that the target vfsmount propogates to,
>>>and those copies will propagate among themselves in the same way that
>>>the copies of the target vfsmount propagate to each other.)
> 
> 
>>ok. that makes sense. As you said the private subtree shall get copied
>>to the new location, however propogations wont be set in either
>>directions. However I have a rather unusual requirement which forces 
>>multiple rbind of a shared subtree within the same shared subtree.
> 
>>I did the calculation and found that the tree simply explodes with
>>vfsstructs.  If I mark a subtree within the larger shared tree as
>>private, then the number of vfsstructs grows linearly O(n). However if
>>there was a way of marking a subtree within the larger shared tree as
>>unclonable than the increase in number of vfsstruct is constant.
> 
>>What I am essentially driving at is, can we add another feature which 
>>allows me to mark a subtree as unclonable?
> 
> 
>>Read below to see how the tree explodes:
> 
>>to run you through an example: 
> 
>>(In case the tree pictures below gets garbled, it can also be seen at 
>> http://www.sudhaa.com/~ram/readahead/sharedsubtree/subtree )
> 
>>step 1:
>>   lets say the root tree has just two directories with one vfsstruct. 
>>                    root
>>                   /    \
>>                  tmp    usr
>>    All I want is to be able to see the entire root tree 
>>   (but not anything under /root/tmp) to be viewable under /root/tmp/m* 
> 
>>step2:
>>      mount --make-shared /root
> 
>>      mkdir -p /tmp/m1
> 
>>      mount --rbind /root /tmp/m1
> 
>>      the new tree now looks like this:
> 
>>                    root
>>                   /    \
>>                 tmp    usr
>>                /
>>               m1
>>              /  \ 
>>             tmp  usr
>>             /
>>            m1
> 
>>          it has two vfsstructs
> 
>>step3: 
>>            mkdir -p /tmp/m2
>>            mount --rbind /root /tmp/m2
> 
> At this step, you probably shouldn't be using --rbind, but --bind
> instead to only bind a copy of the root vfsmount, so it now looks like:
> 
> 
>>                      root
>>                     /    \ 
>>                   tmp     usr
>>                  /    \
>>                m1       m2
>>               / \       /  \
>>             tmp  usr   tmp  usr
>>             / \         / \ 
>>            m1  m2      m1  m2
> 
> 
>> Well I thought about this. Even Bruce Fields suggested this in a private
>> thread. But this solution can be racy. You may have to do multiple binds
>> for all the vfstructs that reside in the subtree under / (but not under
>> /root/tmp). And doing it atomically without racing with other
>> simultaneous mounts would be tricky.
> 

Well, fwiw, I have the same kind of race in autofsng.  I counter it by
building up the vfsmount tree elsewhere and mount --move'ing it.

Unfortunately, the RFC states that moving a shared vfsmount is
prohibited (for which the reasoning slips my mind).


- --
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

iD8DBQFCAUFQdQs4kOxk3/MRAksjAJ4wCzY7jc8aUGKeiHKTywFKxhN1qACeI4HM
eO3XGtYgnbOZJYT3K1nbKd4=
=wwuF
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/