<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
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
