On Mon 27-10-08 22:40:55, Andrew Morton wrote: > On Mon, 27 Oct 2008 13:11:40 +0100 Jan Kara <jack@xxxxxxx> 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@xxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
