[Gluster-devel] Quota-2

Shyam srangana at redhat.com
Fri Dec 18 14:58:10 UTC 2015

<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?

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

More information about the Gluster-devel mailing list