On Tue, Feb 16, 2010 at 03:37:58PM +0300, Dmitry Monakhov wrote: > > Um. Just how is it different from having normal subtrees mounted separately? > > And what's the ID for? > For example for quota needs. With subtree support we can account some > subtree in to corresponding quota_subtree id. What does that have to do with tree topology? Having it inherited from parent is fine, but the rest... If you want to prevent renames/links across an arbitrary subtree boundary, you can already have such policy without any kernel changes; just mount them separately. I'm afraid I still don't get it... I certainly see a point in having some kind of "quota group ID" assigned to fs objects, but that seems to be completely independent from any tree topology considerations. Again, setting up a barrier is as simple as adding /foo/bar /foo/bar none bind,rw 0 0 in /etc/fstab or doing mount --bind /foo/bar /foo/bar when (or after) you've mounted your fs. Or for i in /foo/*; do mount --bind $i $i; done if you want all top-level subdirectories in /foo to be barriers, etc. Either will prevent objects from one subtree to be renamable/linkable from another. Can be arbitrary nested as well... IOW, that looks like a trivially implemented policy that might or might not be desirable for specific setup, but I don't see the reason to tie this quota groups stuff to it or to its reimplementation... -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
