[Gluster-devel] Improvements in Quota Translator

[Brian Foster]

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... ;)

Brian

> Avati
>