Re: [PATCH 02/14] quota: Increase size of variables for limits and inode usage

[Jan Kara <jack@suse.cz>]

On Mon 27-10-08 22:40:55, Andrew Morton wrote:
> On Mon, 27 Oct 2008 13:11:40 +0100 Jan Kara <jack@suse.cz> wrote:
> 
> > So far quota was fine with quota block limits and inode limits/numbers in
> > a 32-bit type. Now with rapid increase in storage sizes there are coming
> > requests to be able to handle quota limits above 4TB / more that 2^32 inodes.
> > So bump up sizes of types in mem_dqblk structure to 64-bits to be able to
> > handle this. Also update inode allocation / checking functions to use qsize_t
> > and make global structure keep quota limits in bytes so that things are
> > consistent.
> > 
> > ...
> >
> >  #define __DQUOT_VERSION__	"dquot_6.5.1"
> >  #define __DQUOT_NUM_VERSION__	6*10000+5*100+1
> 
> This didn't get changed anywhere in the patchset.  Should it have?
  I've just grepped the sources, where these two are used.
__DQUOT_NUM_VERSION__ never - I'll just delete that - and __DQUOT_VERSION__
is printed when initializing quotas - I'll bump version number there. Good
point. Thanks.

> Also, qsize_t is typedefed to a __u64.  But u64's are a pain because
> people keep trying to print them and they often forget the typecast
> and they cause warning storms.
> 
> So until that gets fixed it'd be good to just do
> 
> typedef unsigned long long qsize_t;
> 
> which I think we can trivally do?
  Yep, that's fine.

> Why does qsize_t exist, anyway?  It's always going to be 64-bit, so why
> not open-code `unsigned long long' everywhere.  Or u64?
> 
> I guess it has some readability benefit in certain cases.  It'd be a
> damn sight more useful if we also got compiler typechecking for such
> typedefs, but such is C...
  I don't like writing unsigned long long everywhere, because
1) it's damn long to write ;)
2) (more importantly) when I decide to do 'long long' from qsize_t it's
much harder to find which places need changing and which not. I'm aware
of the rule that one should not introduce unnecessary typedefs and I agree
with it but I find this particular one meaningful ;).

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