Not clear as to why quota 2 must support both DHT v1 and v2. If customers continue to use dht v1, can we not allow them to use quota 1? We need not actively maintain quota v1 but only do reactive fixes. Thanks Naga > On Dec 18, 2015, at 2:30 PM, Vijaikumar Mallikarjuna <vmallika@xxxxxxxxxx> 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 > 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 _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
