Re: [PATCH 08/11] ext4: introduce subtree logic

[Greg Freemyer <greg.freemyer@gmail.com>]

On Tue, Feb 9, 2010 at 5:06 AM, Dmitry Monakhov <dmonakhov@openvz.org> wrote:
> Greg Freemyer <greg.freemyer@gmail.com> writes:
>
>> On Mon, Feb 8, 2010 at 8:28 AM, Dmitry Monakhov <dmonakhov@openvz.org> wrote:
>>> * Abstract
>>>  A subtree of a directory tree T is a tree consisting of a directory
>>>  (the subtree root) in T and all of its descendants in T.
>>>
>>>  Subtree feature allows to create an isolated (from user point of view)
>>>  trees.
>>>
>>>  Subtree assumptions:
>>>  (1) Each inode has subtree id. This id is persistently stored inside
>>>      inode (xattr, usually inside ibody)
>>>  (2) Subtree id is inherent from parent directory
>>>  (3) Inode can not belongs to different subtree
>>>      Otherwise changes in one subtree result in changes in other subtree
>>>      which contradict to isolation criteria.
>>>
>>>  This feature is similar to project-id in XFS. One may assign some id to
>>>  a subtree. Each entry from the subtree may be accounted in directory
>>>  subtree quota. Will appear in later patches.
>>>
>>> * Disk layout
>>>  Subtree id is stored on disk inside xattr usually inside ibody.
>>>  Xattr is used only as a data storage, It has not user visiable xattr
>>>  interface.
>>>
>>> Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
>>
>> Dmitry,
>>
>> I think the idea of subtrees is useful, but I'm curious about other
>> use cases than just quota.
>>
>> At first glance you are attempting to create a generic subtree
>> functionality for ext4, but criteria 3) above says a inode can only be
>> in one subtree at a time.
> Theoretically this is possible, but this dramatically complicate things
> Just think about this. If inode belongs to different subtrees then
> it must have several tree-dquota objects attached to it. This means
> that quota require great quota redesign.
> Obviously i don't know any use case for this feature. do you know any?

Maybe we're talking about different things.  I working with the OHSM
project <http://ohsm.sourceforge.net/>

We haven't submitted any patches yet, but for one of our features we
have something fairly close to your subtree patch.  If we were to
leverage your patch and drop that part of ours we would be in the
unhappy situation that quota and ohsm could not both be enabled on the
same filesystem because the ohsm subtree geography is not likely to be
consistent with the quota subtree geography.

If we call quota and ohsm services then my desire would be to see your
subtree patches support orthoganal subtree groups.  One group per
service.

I haven't looked into the actual implementation, but from an API
perspective it is just a matter of adding a service parameter to the
various calls.  For a given subtree service group, a given inode could
only be part of one subtree, but a single inode could participate in
multiple subtree service groups.

Greg
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html