Re: [PATCH] quota: additional range checks and mem_dqblk updates?to handle 64-bit limits

[Zhiyong Landen tian <Zhiyong.Tian@Sun.COM>]

Jan Kara wrote:
> On Sat 08-03-08 03:56:17, Andrew Perepechko wrote:
>   
>> Jan, this idea would work for us for now. As Andreas pointed out, we deal 
>> with MB-aligned quota limits, so this would give us the largest possible block 
>> quota limit value of 4 PB.
>>
>> However, I feel that it is worth to implement a clean 64-bit format, so that
>> we avoid additional semantics (like quota unit size) and do make quota scale 
>> better (4 PB clusters already exist).
>>     
>   Wow. I wonder when 64-bits won't be enough :). Anyway, my point was that
> when you get to 4 PB limits, you can just run: "setquota --set-scale 1GB"
> (hopefully at that time you won't care about rounding limits to 1GB) and
> you are at 4 HB limits (or what is the right suffix). No quota format
> change needed.
>   But what I fear more is that we may run out of 2^32 limit on the number
> of files one user can have (I don't have experience with that large systems
> but I guess you are comming near to 2^32 files on the filesystem, aren't
> you?). And for that we would have to do basically the changes you've
> suggested
The core of the "scale" way is: it does harm to the accuracy of quota so 
that we can set a larger
quota limitation. If the scale is 1G, 500M quota the user sets is equal 
to 0. Some customers may
like it; others may confuse. Anyway, we can't regulate the way of users 
using quota.

For lustre, I have a plan to set a minimum unit to 1K instead of current 
1M. So 64bit quota is
a must. I just wonder why not we implement these two points in different 
patches:
1. 64bit quota limitation
2. give a "scale" to the users who are glad to adjust it.