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

[Eric Sandeen <sandeen@sandeen.net>]

On 1/27/16 11:17 AM, Eric Sandeen wrote:
> On 1/27/16 9:37 AM, Carlos Maiolino wrote:
>>>>
>>>> This patch aims to split the default quota value by quota type. Allowing each
>>>> quota type having different default values.
>>>>
>>>> Default time limits are still set globally, but I don't mind to split them by
>>>> quota type too.
>>>
>>> Hm, I guess it seems like it should be done; otherwise it's a weird
>>> caveat, isn't it?  "Default limits are set by type, but timers are
>>> inherited from whatever first default quota is found across all types"
>>>
>>> So yeah, seems like it should be done for timers as well, IMHO;
>>> grace periods can be set for each default quota type, so they should
>>> be honored.
>>>
>>
>> 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.
> 
> yeah, sorry about that.  I forgot that they were fs-wide, but that makes sense.
> Sorry for leading you astray.

Ugh, this is a mess.  The xfs_quota command says:

       timer [ -gpu ] [ -bir ] value

we can indeed set timers for each type; group, project, and user.
These really are stored on-disk for ID 0 for each type.
We can set different values for user, group, and project.

However, let's set the inode timer for group quota to 30 minutes:

# xfs_quota -x -c "timer -i -g 30m" /dev/sdb1
# xfs_quota -x -c "state" /dev/sdb1 | grep grace
Blocks grace time: [7 days 00:00:30]
Inodes grace time: [0 days 00:30:30]

Uh, ok, it set a global default.  (And where did the 30s come
from?)

Now let's set an inode timer for *user* quota:

# xfs_quota -x -c "timer -i -u 60m" /dev/sdb1
# xfs_quota -x -c "state" /dev/sdb1 | grep grace
Blocks grace time: [7 days 00:00:30]
Inodes grace time: [0 days 01:00:30]

Uh, ok, now that's the grace time...

Go back to group quota, try something smaller?

# xfs_quota -x -c "timer -i -g 10m" /dev/sdb1
# xfs_quota -x -c "state" /dev/sdb1 | grep grace
Blocks grace time: [7 days 00:00:30]
Inodes grace time: [0 days 00:10:30]

Ok, seems that "type" doesn't matter, and whatever was set last wins.  Except:

<remount>

# xfs_quota -x -c "state" /dev/sdb1 | grep grace
Blocks grace time: [7 days 00:00:30]
Inodes grace time: [0 days 01:00:30]

ohai, now we are back to the user quota we set, because that's checked first.  :(

(with your most recent patch, it'll be whatever is checked *last*).

So this is all a big steaming pile, right down to the "timer"
command help giving you options it won't accept (-d), or ignores (id|name).

I guess it seems ok to just break out default limits into per-type limits; that's
a decent step in the right direction.  We probably need to think more about
how the timers should work; do we really want them to be global?  The tool
certainly reports them as such, although it claims to set them per-type.

Anyway, changes you make for per-type limits probably shouldn't change
how time limits are interpreted, but today they do.

...

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs