[Gluster-devel] Improvements in Quota Translator

[Vijay Bellur]

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