On 1/27/16 9:37 AM, Carlos Maiolino wrote:
> Ok, I was just working on implement it, but honestly, I don't see the point now
> in split time limits by user/group/project.
>
> grace periods are set globally by default. We don't have specific quota grace
> limits for each user or each group. Just a single value for them.
>
> So, if we can not specify an individual grace period per-user or per-group, what
> is the point in having these time limits split by user/group/project? We could
> have the values divided by user/group/proj, but what's the sense on it? If we
> have a default grace limit for users, it will be set to all users, if we have a
> grace limit for groups, it will be enforced to all users anyway (since we can't
> specify the group here either).
>
> So, I wonder, does it make sense?
>
> Looks a nice idea for the future, but for the current implementation it doesn't
> make sense to me. But sure, let me know if I'm wrong :)
Sorry for all the self-replies.
I'm thinking that this really should be fixed up along with this work.
The time limits aren't about per-user or per-group; they are in fact filesystem-wide.
However, it is possible today to set time limits for user quota, group quota,
or project quota - i.e. not for each user, but for the user *type*; not for
each group, but for the group *type*.
Fixing it should be as "easy" as moving those time limits into your default
quotas structures. It'd come almost for free in xfs_qm_init_quotainfo().
xfs_qm_adjust_dqtimers() then needs to use those, and
xfs_qm_fill_state() should get the proper values for each type, as well.
But the problem may be in reporting back out to userspace via
quota_getstate():
/*
* GETXSTATE quotactl has space for just one set of time limits so
* report them for the first enabled quota type
*/
o_O doesn't that suck!
quota_getstatev() has enough padding that we could report it all out, though,
with some changes.
-Eric
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
