xfs
[Top] [All Lists]

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

To: xfs@xxxxxxxxxxx
Subject: Re: [PATCH] Split default quota limits by quota type
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Wed, 27 Jan 2016 13:06:45 -0600
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <56A8FBA9.3060205@xxxxxxxxxxx>
References: <1453303127-27295-1-git-send-email-cmaiolino@xxxxxxxxxx> <569FC41E.2040300@xxxxxxxxxxx> <20160127153705.GA17571@xxxxxxxxxx> <56A8FBA9.3060205@xxxxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
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

<Prev in Thread] Current Thread [Next in Thread>