[Gluster-devel] Quota-2

[Venky Shankar]

Shyam wrote:
> <first off the cuff response>
>
> On 12/18/2015 04:00 AM, Vijaikumar Mallikarjuna wrote:
>> Hi All,
>>
>> Here is the summary of discussion we had today on Quota-v2
>>
>> Project, user and group quotas will use the same logic of accounting the
>> usage
>>
>> Quota-v2 should be compatible with both DHT-v1 and DHT-v2
>>
>> Project quotas will use gfid of the given path as the project-id.
>> each inode will have a associated project-id which needs to be
>> embedded within inode.
>> when creating new file, it will inherit project-id from its parent
>> inode.
>> In case if parent inode doesn't contain project-id, then there
>> should be a mechanism to
>> find the project-id given a gfid, so back-pointers can solve this
>> problem
>
> Why would the parent not contain a project-id? and if it does not
> contain a project-id, why would you need to find a project-id?

Updating project-id's for all children for a given directory on which a 
project-id is set would required scanning. If we could figure
out the project-id for a given inode using back-pointers (closest 
ancestor for which a project-id is set) then we'd not need the crawl and 
update.

With DHT2, such a mechanism would query each MDS. For current DHT, it 
might still be good enough.

>
> What I can visualize is that, the parent is not yet part of a quota
> project, hence it does not contain a project-id. When this becomes a
> part of some quota restriction it would start getting a quota. This
> seems to be one case where the project-id would be missing, but by choice.
>
> What am I missing here?
>
>> which xlator DHT/marker will set the project-id in the inode? this
>> needs to be decided
>> User and group quotas will use uid and gid to account the usage
>>
>> Quota has below set of operation which should be performed as a single
>> transaction
>> read current size
>> read current contribution
>> update delta to the contribution
>> update size to user/project inode
>> In the current directory quota, to make this transaction crash
>> consistent we use a mechanism of setting dirty flag in a parent inode.
>> This mechanism will not work efficiently with project quotas. Journaling
>> will be the good solution for crash-consistency.
>>
>> Quota 2 depends on:
>> back-pointers: to find project-id from gfid
>> journaling: for crash consistency of accounting
>>
>>
>> Thanks,
>> Vijay