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

[Andrew Perepechko <Andrew.Perepechko@Sun.COM>]

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).

Do you feel it might take considerably larger efforts to update quotatools
to 64-bit version compared to 32-bit version with variable quota unit size?

I'd like to start working on a kernel patch implementing 64-bit limits provided 
you approve the approach.

Of course, it seems to be a good idea to have different file names for each version,
not only for each format (where format and version have the same meaning
as in quota kernel modules). The drawback is that then journalling quota users 
need to know the exact quota file version, not only format...

Thank you for you kind response.
Andrew.


On Friday 07 March 2008 19:00:43 Jan Kara wrote:
>   Great, thanks. The patch is fine. Yesterday evening I got an idea, how to
> solve your problem with too low limits even easier. What we could do is to
> introduce a "block-limit-scale" and "inode-limit-scale" parameter to the
> quota info and we keep the rest of the file format the same. Now, the meaning
> of this parameter would simply be a unit in which space and inode limits
> are specified. When you have a filesystem where you'd like to set quotas
> over 4 TB, you probably don't want to specify limits with 1KB precision
> anyway... So you can just set scale to 1MB or even 16MB (giving you maximal
> limit of 64 PB) and 10000 files or so. This has two advantages - only a few
> trivial modifications to current kernel code, no change in quota file space
> usage. We could then provide a way to set this scale via setquota / edquota
> (which would have to convert the whole file but that should be no big deal).
>   What do you think about such solution? Would it fit your needs? Sorry,
> that I haven't through of this solution earlier...
> 								Honza