[Gluster-devel] Quota-2

[Shyam]

On 12/20/2015 10:57 PM, Vijaikumar Mallikarjuna wrote:
>
>
> On Fri, Dec 18, 2015 at 8:28 PM, Shyam <srangana at redhat.com
> <mailto:srangana at redhat.com>> 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?
>
>     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?
>
> There are two scenarios where project-id can be missing
> 1) When quota is enabled on a pre-existing data,

I would assume there would be a sub-tree walk here that marks the 
existing data with the project-id and hence start accounting. As a 
result in this case we should not need to traverse when creating an 
entry just to hunt for a possible project-id, the sub-tree walk would 
get to this entry during its walk.

> 2) Directory created when one of the brick is down

Again, this should be a part of the heal, i.e when the directory is 
created on the brick that was down, it should get marked with the right 
inode information (project-id in this case). Further objects can be 
created under this directory only when the directory itself is created, 
as a result, if we tackle the problem during directory heal/creation on 
the down brick, we should not have to traverse backward to get the 
potential project-id.

Thoughts?

>
> Thanks,
> Vijay
>
>
>               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
>
>