Re: [RFC] vfs generic subtree support

[Dmitry Monakhov <dmonakhov@openvz.org>]

Al Viro <viro@ZenIV.linux.org.uk> writes:

> 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.
Agree "subtree" is not really good word this. Because it may be useful
not only for subtrees. Also "quota group id" IMHO not really good (at
leas it is ambiguous).

Let's call it "metagroup" id. If you know better (more descriptive) word
for this purpose i please make your suggestion.

- Such metagroup may be assigned to inode. And this id is stored on
  inode.
- It may be inherent from parent, if corresponding flag is set 
  on parent dir.
- metagroup id may be used by generic quota.
- metagroup id has no in common with link/rename behavior,
  bind mount is responsible for such behavior.
Are you agree with following conception?
>
> 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...