From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kara Subject: Re: [PATCH 02/14] quota: Increase size of variables for limits and inode usage Date: Wed, 29 Oct 2008 04:01:45 +0100 Message-ID: <20081029030145.GK24732@duck.suse.cz> References: <1225109512852-git-send-email-jack@suse.cz> <12251095123763-git-send-email-jack@suse.cz> <12251095124166-git-send-email-jack@suse.cz> <20081027224055.698a4ed6.akpm@linux-foundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jan Kara , linux-fsdevel@vger.kernel.org To: Andrew Morton Return-path: Received: from styx.suse.cz ([82.119.242.94]:47264 "EHLO mail.suse.cz" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752144AbYJ2DBr (ORCPT ); Tue, 28 Oct 2008 23:01:47 -0400 Content-Disposition: inline In-Reply-To: <20081027224055.698a4ed6.akpm@linux-foundation.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon 27-10-08 22:40:55, Andrew Morton wrote: > On Mon, 27 Oct 2008 13:11:40 +0100 Jan Kara 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 SUSE Labs, CR