From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: [PATCH 1/2] ext3 percpu counter fixes to suppport for more than 2**31 ext3 free blocks counter Date: Fri, 21 Apr 2006 15:09:43 -0700 Message-ID: <20060421150943.2fdc5c4a.akpm@osdl.org> References: <1144691929.3964.53.camel@dyn9047017067.beaverton.ibm.com> <1145631546.4478.10.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: kiran@scalex86.org, LaurentVivier@wanadoo.fr, sct@redhat.com, linux-kernel@vger.kernel.org, ext2-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org Return-path: Received: from smtp.osdl.org ([65.172.181.4]:61896 "EHLO smtp.osdl.org") by vger.kernel.org with ESMTP id S1750821AbWDUWH2 (ORCPT ); Fri, 21 Apr 2006 18:07:28 -0400 To: cmm@us.ibm.com In-Reply-To: <1145631546.4478.10.camel@localhost.localdomain> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Mingming Cao wrote: > > The following patches are to fix the percpu counter issue support more > than 2**31 blocks for ext3, i.e. allow the ext3 free block accounting > works with more than 8TB storage. > > [PATCH 1] - Generic perpcu longlong type counter support: global counter > type changed from long to long long. The local counter is still remains > 32 bit (long type), so we could avoid doing 64 bit update in most cases. > Fixed the percpu_counter_read_positive() to handle the 0 value counter > correctly;Add support to initialize the global counter to a value that > are greater than 2**32. I think it would be saner to explicitly specify the size of the field. That means using s32 and s64 throughout this code. That'll actually save space on 64-bit machines, where we're presently doing alloc_percpu(long) when all we need is alloc_percpu(s32). We'd need to review all users of this interface to make sure that they handle the changed sizes appropriately, too.