From: Al Viro <viro@ZenIV.linux.org.uk>
To: Dmitry Monakhov <dmonakhov@openvz.org>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: [RFC] vfs generic subtree support
Date: Tue, 16 Feb 2010 13:38:36 +0000 [thread overview]
Message-ID: <20100216133836.GD30031@ZenIV.linux.org.uk> (raw)
In-Reply-To: <87bpfpcq55.fsf@openvz.org>
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...
next prev parent reply other threads:[~2010-02-16 13:38 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-16 10:52 [RFC] vfs generic subtree support Dmitry Monakhov
2010-02-16 12:20 ` Al Viro
2010-02-16 12:37 ` Dmitry Monakhov
2010-02-16 13:38 ` Al Viro [this message]
2010-02-16 14:01 ` Dmitry Monakhov
2010-02-16 14:21 ` Al Viro
2010-02-16 15:00 ` Dmitry Monakhov
2010-02-16 15:12 ` Matthew Wilcox
2010-02-16 15:32 ` Dmitry Monakhov
2010-02-16 19:25 ` J. Bruce Fields
2010-02-16 19:32 ` Christoph Hellwig
2010-02-16 19:39 ` J. Bruce Fields
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100216133836.GD30031@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=dmonakhov@openvz.org \
--cc=linux-fsdevel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.