All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Monakhov <dmonakhov@openvz.org>
To: Jan Kara <jack@suse.cz>
Cc: linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org
Subject: Re: [PATCH 4/5] ext4: add isolated project support
Date: Thu, 04 Mar 2010 23:34:43 +0300	[thread overview]
Message-ID: <87sk8fbzbw.fsf@openvz.org> (raw)
In-Reply-To: <20100304200700.GA6092@atrey.karlin.mff.cuni.cz> (Jan Kara's message of "Thu, 4 Mar 2010 21:07:00 +0100")

Jan Kara <jack@suse.cz> writes:

>   Hi,
>
>> PROJECT_ISOLATION
>> This feature allows to create an isolated project subtrees.
>> Isolation means what:
>>   1) directory subtree has no common inodes (no hadlinks across subtrees)
>>   2) All descendants belongs to the same subtree.
>> 
>> Project subtree's isolation assumptions:
>>   1)Inode can not belongs to different subtree trees
>>     Otherwise changes in one subtree result in changes in other subtree
>>     which contradict to isolation criteria.
>   Just a curious question:
> Do you really need this subtree separation in your envisioned containers
> usecase? Because there I imagine you have one project_id per container,
> containers form disjoint subtrees (at least their writeable parts) and
> each file & directory has this project_id set and you forbid to manipulate
> project id's from inside the container (otherwise you'd have problems with
> enforcing quota limits I guess).
>
> And when project_id is a per-inode property, quota has no problems with it
> (is well defined) even without subtree separation. So is this subtree
> separation really needed?
You right containers dealt with with only one subtree so bindmount
is sufficient for all container's like sulutions.
I've done this isolation part after long discussion with Dave Chinner
He give some examples there fs-specific (not mount ones) isolation
is useful. Most obvious usage example of project which has several
trees. He intend that this feature is used by XFS users.
But this feature attract most complains from reviewers, and i'll drop
it if will be necessary to merge the project-id quota.
>
> 								Honza

  reply	other threads:[~2010-03-04 20:34 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-04 18:34 [PATCH 0/5] RFC: introduce extended inode owner identifier v5 Dmitry Monakhov
2010-03-04 18:34 ` [PATCH 1/5] vfs: Add additional owner identifier Dmitry Monakhov
2010-03-04 18:34   ` [PATCH 2/5] quota: Implement project id support for generic quota Dmitry Monakhov
2010-03-04 18:34     ` [PATCH 3/5] ext4: Implement project ID support for ext4 filesystem Dmitry Monakhov
2010-03-04 18:34       ` [PATCH 4/5] ext4: add isolated project support Dmitry Monakhov
2010-03-04 18:34         ` [PATCH 5/5] ext4: add project quota support Dmitry Monakhov
2010-03-04 20:07         ` [PATCH 4/5] ext4: add isolated project support Jan Kara
2010-03-04 20:34           ` Dmitry Monakhov [this message]
2010-03-11 12:07         ` Christoph Hellwig
2010-03-11 12:06       ` [PATCH 3/5] ext4: Implement project ID support for ext4 filesystem Christoph Hellwig
2010-03-11 13:30         ` Dmitry Monakhov
2010-03-11 19:54           ` Andreas Dilger
2010-03-11 22:01             ` tytso
2010-03-12  9:32               ` Dmitry Monakhov
2010-03-12 20:07                 ` J. Bruce Fields
2010-03-11 12:03     ` [PATCH 2/5] quota: Implement project id support for generic quota Christoph Hellwig
2010-03-11 13:17       ` Dmitry Monakhov
2010-03-11 12:01   ` [PATCH 1/5] vfs: Add additional owner identifier Christoph Hellwig
2010-03-11 13:11     ` Dmitry Monakhov
2010-03-11 18:51       ` J. Bruce Fields
2010-03-11 19:40         ` Andreas Dilger
2010-03-12  8:47           ` Dmitry Monakhov

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=87sk8fbzbw.fsf@openvz.org \
    --to=dmonakhov@openvz.org \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.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.