From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [RFC] vfs generic subtree support Date: Tue, 16 Feb 2010 13:38:36 +0000 Message-ID: <20100216133836.GD30031@ZenIV.linux.org.uk> References: <87tythtptw.fsf@openvz.org> <20100216122029.GC30031@ZenIV.linux.org.uk> <87bpfpcq55.fsf@openvz.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org To: Dmitry Monakhov Return-path: Received: from zeniv.linux.org.uk ([195.92.253.2]:38290 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756180Ab0BPNih (ORCPT ); Tue, 16 Feb 2010 08:38:37 -0500 Content-Disposition: inline In-Reply-To: <87bpfpcq55.fsf@openvz.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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...