On 12/20/2015 10:57 PM, Vijaikumar Mallikarjuna wrote:
On Fri, Dec 18, 2015 at 8:28 PM, Shyam <[email protected]
<mailto:[email protected]>> 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
_______________________________________________
Gluster-devel mailing list
[email protected]
http://www.gluster.org/mailman/listinfo/gluster-devel
