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

[Jan Kara <jack@suse.cz>]

On Fri 07-03-08 14:10:39, Andreas Dilger wrote:
> On Mar 07, 2008  17:00 +0100, Jan Kara wrote:
> > On Fri 07-03-08 03:29:29, Andrew Perepechko 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...
> 
> I can't speak fully for Andrew, as he is one of our quota gurus, but my
> thought is that there is a risk of introducing corruption into the quota
> file while it is entirely being rewritten and the system crashes or is
> rebooted because the admin is impatient if this takes a long time.
> 
> Moving to a second quota file is pretty safe, can be done incrementally
> (i.e. check new file and then old file, if it exists) and allows a fallback
> if the update fails in the middle.
  This rewriting is going to happen from tools in userspace - i.e., you
turn quotas off, run a tool which does the conversion - it will create new
converted file and just it move over the old file when it's done. So I
think this should be no issue.

> Also, while the "scale" parameter has merit in allowing the upper limit
> of quota to be changed, the problem still exists on how to measure the
> actual quota usage in that case.  If we assume a scale of 1MB (which is
> fine for Lustre, that is the minimum we grant quota to different servers
> anyways :-) but some user is only consuming 100k of quota at a time, then
> this will continually be rounded down to 0 quota usage...
  Quota usage is already measured in bytes and the format has 64-bit field
for it already. So that's no problem. But I've just realized we might have
a problem in case we want to allow user to have more that 2^32 files as
the number of files user has is stored in a 32-bit field.

									Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR