[Gluster-devel] Improvements in Quota Translator

[Anand Babu Periasamy]

On Mon, Apr 15, 2013 at 1:19 PM, Vijay Bellur <vbellur at redhat.com> wrote:

> On 04/11/2013 05:12 AM, Brian Foster wrote:
>
>> On 04/10/2013 06:44 PM, Anand Avati wrote:
>>
>>>
>>> On Apr 10, 2013, at 2:50 PM, Brian Foster <bfoster at redhat.com> wrote:
>>>
>>>  On 04/10/2013 03:06 PM, Anand Avati wrote:
>>>>
>>>>>
>>>>> On Apr 10, 2013, at 6:10 AM, Jeff Darcy <jdarcy at redhat.com> wrote:
>>>>>
>>>>>> Since XFS doesn't allow hard links across directory tree quota
>>>>>>> boundaries - we get EXDEV, it would prevent gluster from creation
>>>>>>> ".glusterfs" directory entries. So Gluster quota does both accounting
>>>>>>> and enforcing of quota.
>>>>>>>
>>>>>>
>>>>>> Well, that's certainly an unfortunate consequence of using links
>>>>>> instead
>>>>>> of a log to track dirty files.  :(  One more reason to undo that
>>>>>> damage,
>>>>>> I suppose, but that's a different thread.
>>>>>>
>>>>>
>>>>> The problem here is with the gfid hard links (for providing stable
>>>>> file handles). Index uses hard links from an internal backing file which is
>>>>> also created within .glusterfs - the actual dirty files are never linked
>>>>> into index. While we do want to make index use a different format, it is
>>>>> completely unrelated (in fact not a problem at all) to the XFS quota issue
>>>>> - which is linking of true files into .glusterfs for providing stable file
>>>>> handles.
>>>>>
>>>>>
>>>> I went looking into this behavior because I don't recall running into it
>>>> before. I can reproduce EXDEV if I try link from project quota A to
>>>> project quota B but it looks like this only enforced when the target
>>>> directory has project quota inheritance enabled (to prevent writing a
>>>> file somewhere and linking it into a directory under quota, XFS enforces
>>>> that the project quota IDs must match).
>>>>
>>>> I can create a file under a project quota and link it out of the project
>>>> quota subtree without an error. So you could create a file under a
>>>> project quota and link it under .glusterfs, but not vice versa and not
>>>> into another directory covered by a project quota.
>>>>
>>>
>>> I suppose this would be a problem if we set a quota limit on the volume
>>> top level, as .glusterfs is a subdirectory of the export directory?
>>>
>>>
>> I don't think it's a severe problem. Project quotas in XFS are tracked
>> via a project ID inode field, just like a uid or gid, only inherited via
>> parent directory. One could conceivably set a project ID on / and
>> recursively through every file and directory in the tree with the
>> exception of /.glusterfs (where / refers to brick root directory).
>>
>> It gets a bit hairier if you want to support subquotas because you now
>> have to emulate subquota accounting/enforcement on top of traditional
>> project quota accounting (along with dealing with the management of
>> project IDs between subquotas and whatnot).
>>
>> I'm sure there are other caveats as well, such as management of project
>> quotas across separate volumes on the same filesystem, etc., so I'm not
>> necessarily saying this is the way to go or not... ;)
>>
>>
> I think we can consider both approaches - improving the current
> implementation of quotas that we have today and leveraging xfs project
> quotas. The former looks like something which can be implemented near term
> since most of the details are in place. The latter  approach can be picked
> up once the investigations are complete and we have a more detailed
> understanding of the implementation details.
>
> -Vijay
>
>
> I think we should agree to get one of the quota implementation right. If
we have both, it is harder to test, document and maintain the code base.

My first preference will be to leverage disk filesystem based quotas where
we support at least xfs and ext4 to begin with. If we think we can do much
better quota implementation entirely within the translator layer, I am
supportive of it.,

-ab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20130415/788230ff/attachment-0001.html>