Re: [PATCH] Split default quota limits by quota type

[Eric Sandeen <sandeen@sandeen.net>]

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@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs