This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Fri Apr 19 05:10:45 2024 Delivery-date: Mon, 10 Apr 2006 21:07:41 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932116AbWDJTG6 (ORCPT ); Mon, 10 Apr 2006 15:06:58 -0400 Received: from e31.co.us.ibm.com ([32.97.110.149]:34970 "EHLO e31.co.us.ibm.com") by vger.kernel.org with ESMTP id S932115AbWDJTG4 (ORCPT ); Mon, 10 Apr 2006 15:06:56 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e31.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k3AJ6sGr022822; Mon, 10 Apr 2006 15:06:54 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k3AJAB6e055164; Mon, 10 Apr 2006 13:10:11 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id k3AJ6rGV021612; Mon, 10 Apr 2006 13:06:54 -0600 Received: from dyn9047017067.beaverton.ibm.com (dyn9047017067.beaverton.ibm.com [9.47.17.67]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id k3AJ6qxP021568; Mon, 10 Apr 2006 13:06:52 -0600 Subject: Re: [Ext2-devel] Re: [RFC][PATCH 0/2]Extend ext3 filesystem limit from 8TB to 16TB From: Mingming Cao Reply-To: cmm@us.ibm.com To: Laurent Vivier , kiran@scalex86.org Cc: Andrew Morton , Takashi Sato , linux-kernel@vger.kernel.org, ext2-devel , linux-fsdevel@vger.kernel.org In-Reply-To: <1144688279.3964.7.camel@dyn9047017067.beaverton.ibm.com> References: <20060325223358sho@rifu.tnes.nec.co.jp> <1143485147.3970.23.camel@dyn9047017067.beaverton.ibm.com> <20060327131049.2c6a5413.akpm@osdl.org> <20060327225847.GC3756@localhost.localdomain> <1143530126.11560.6.camel@openx2.frec.bull.fr> <1143568905.3935. Content-Type: text/plain; charset=UTF-8 Organization: IBM LTC Date: Mon, 10 Apr 2006 12:06:51 -0700 Message-Id: <1144696012.3964.76.camel@dyn9047017067.beaverton.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2006-04-10 at 09:57 -0700, Mingming Cao wrote: > On Mon, 2006-04-10 at 11:11 +0200, Laurent Vivier wrote: > > Le jeu 30/03/2006 =C3=A0 03:54, Andrew Morton a =C3=A9crit : > > > Mingming Cao wrote: > > > > > > > > The things need to be done to complete this work is the issue w= ith > > > > current percpu counter, which could not handle u32 type count = well.=20 > > >=20 > > > I'm surprised there's much of a problem here. It is a 32-bit val= ue, so it > > > should mainly be a matter of treating the return value from > > > percpu_counter_read() as unsigned long. > > >=20 > > > However a stickier problem is when dealing with a filesystem whic= h has, > > > say, 0xffff_ff00 blocks. Because percpu counters are approximate= , and a > > > counter which really has a value of 0xffff_feee might return 0x00= 000123.=20 > > > What do we do then? > > >=20 > > > Of course the simple option is to nuke the percpu counters in ext= 3 and use > > > atomic_long_t (which is signed, so appropriate treat-it-as-unsign= ed code > > > would be needed). I doubt if the percpu counters in ext3 are gai= ning us > > > much. > >=20 > > I tried to make something in this way. > > Does the attached patch look like the thing you though about ? > >=20 >=20 Hi Laurent, Just looked at your patch, shouldn't we use atomic_long_add() instead o= f atomic_long_set() to replace percpu_counter_mod()? > I tried the other way -- I am trying to keep the percpu counter in us= e > in ext2/3 as much as possible. I proposed a fix for percpu counter t= o > deal with the possible "overflow" (i.e, a counter really has a value = of > 0xfff_feee and after updating one local counter it truens 0x00000123)= =2E > Will send the proposed patch out for review and comments soon. >=20 Anyway, I am not against the atomic way. Just thought there must be reasons where we use percpu counters -- the cache pollution on smp machine is certainly a concern if we use atomic instead, so I tried to fix percpu counter first. I think my fix for percpu counter should work, and the changes doesn't affect other users of current percpu counters(vfs and network). Kiran, Andrew, please review it (posted in another seperate thread). If not, then I guess we have to use atomic counter -- this is performance vs capacity kind of trade off. But both methods don't support 64 bit ext3 block number on 32 bit machine...I am not happy with this but can't think of a way to fix this without taking a global lock:( Mingming > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting la= nguage > that extends applications into web and mobile media. Attend the live = webcast > and join the prime developer group breaking into this new coding terr= itory! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=110944&bid$1720&dat=121= 642 > _______________________________________________ > Ext2-devel mailing list > Ext2-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ext2-devel - To unsubscribe from this list: send the line "unsubscribe linux-kernel"= in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/