[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87sk8fbzbw.fsf@openvz.org>
Date: Thu, 04 Mar 2010 23:34:43 +0300
From: Dmitry Monakhov <dmonakhov@...nvz.org>
To: Jan Kara <jack@...e.cz>
Cc: linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org
Subject: Re: [PATCH 4/5] ext4: add isolated project support
Jan Kara <jack@...e.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
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists