From: Mingming Cao <cmm@us.ibm.com>
To: Andrew Morton <akpm@osdl.org>
Cc: sho@tnes.nec.co.jp, Laurent.Vivier@bull.net,
linux-kernel@vger.kernel.org, ext2-devel@lists.sourceforge.net,
linux-fsdevel@vger.kernel.org
Subject: Re: [RFC][PATCH 0/2]Extend ext3 filesystem limit from 8TB to 16TB
Date: Sun, 02 Apr 2006 13:13:21 -0700 [thread overview]
Message-ID: <1144008802.29210.16.camel@localhost.localdomain> (raw)
In-Reply-To: <1143844943.3944.22.camel@dyn9047017067.beaverton.ibm.com>
On Fri, 2006-03-31 at 14:42 -0800, Mingming Cao wrote:
> On Wed, 2006-03-29 at 17:54 -0800, Andrew Morton wrote:
> > Mingming Cao <cmm@us.ibm.com> wrote:
> > >
> > > The things need to be done to complete this work is the issue with
> > > current percpu counter, which could not handle u32 type count well.
> >
> > I'm surprised there's much of a problem here. It is a 32-bit value, so it
> > should mainly be a matter of treating the return value from
> > percpu_counter_read() as unsigned long.
> >
> > However a stickier problem is when dealing with a filesystem which has,
> > say, 0xffff_ff00 blocks. Because percpu counters are approximate, and a
> > counter which really has a value of 0xffff_feee might return 0x00000123.
> > What do we do then?
> >
>
> Hmm... I think we had this issue already even with today's 2**31 ext3.
> Since ext2/3 always use percpu_counter_read_positive() to get the total
> number of free blocks, so if the real free blocks is 0x0fff_feee, and
> the approximate value from the percpu counter is 0xf000_0123, the
> percpu_counter_read_positive() will return back 0x0000123.
>
In fact, even worse, percpu_counter_read_positive() always return 1 if
the value is negative (>2**31). So this is not suitable for ext3's
2**32 block numbers. I think we should use percpu_counter_read() and
cast it to unsigned long for ext3's free blocks (and probably for free
inodes also).
Think over again, I think we could fix the possible overflow issue
(caused by approximate value) Andrew was concerned about: Before update
the global counter, check to see if we are trying to increase the global
counter but get a smaller value, or we are trying to decrease the global
counter but instead get a larger value. If any of them is true, we
should not update the global counter at that moment. This check only
happens when try to update the global counter from an local counter, and
probably not needed for those who don't care about unsigned long
counters. This way we shall not get ridiculous values from the counter.
Comments?
Mingming
next prev parent reply other threads:[~2006-04-02 20:18 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20060325223358sho@rifu.tnes.nec.co.jp>
[not found] ` <1143485147.3970.23.camel@dyn9047017067.beaverton.ibm.com>
[not found] ` <20060327131049.2c6a5413.akpm@osdl.org>
[not found] ` <20060327225847.GC3756@localhost.localdomain>
[not found] ` <1143530126.11560.6.camel@openx2.frec.bull.fr>
[not found] ` <1143568905.3935.13.camel@dyn9047017067.beaverton.ibm.com>
[not found] ` <1143623605.5046.11.camel@openx2.frec.bull.fr>
2006-03-30 1:38 ` [RFC][PATCH 0/2]Extend ext3 filesystem limit from 8TB to 16TB Mingming Cao
2006-03-30 1:54 ` Andrew Morton
2006-03-31 22:42 ` Mingming Cao
2006-04-02 20:13 ` Mingming Cao [this message]
2006-04-10 9:11 ` [Ext2-devel] " Laurent Vivier
2006-04-10 8:24 ` Andrew Morton
2006-04-13 15:26 ` Laurent Vivier
2006-04-17 21:07 ` Ravikiran G Thirumalai
2006-04-17 21:09 ` Arjan van de Ven
2006-04-17 21:32 ` Ravikiran G Thirumalai
2006-04-18 7:14 ` Laurent Vivier
2006-04-18 7:30 ` [Ext2-devel] " Arjan van de Ven
2006-04-18 10:57 ` Laurent Vivier
2006-04-18 19:08 ` Ravikiran G Thirumalai
2006-04-18 14:09 ` Laurent Vivier
2006-04-18 21:01 ` [Ext2-devel] " Mingming Cao
2006-04-20 11:28 ` Laurent Vivier
2006-04-20 14:39 ` Laurent Vivier
2006-04-21 11:17 ` [Ext2-devel] " Laurent Vivier
2006-04-10 16:57 ` Mingming Cao
2006-04-10 19:06 ` Mingming Cao
2006-04-11 7:07 ` Laurent Vivier
2006-04-14 17:23 ` [Ext2-devel] " Ravikiran G Thirumalai
2006-03-30 17:36 ` Andreas Dilger
2006-03-30 19:01 ` Mingming Cao
2006-03-30 17:40 ` Andreas Dilger
2006-03-30 19:16 ` Mingming Cao
2006-03-30 19:22 ` Mingming Cao
2006-03-31 6:42 ` Andreas Dilger
2006-03-31 13:33 ` Andi Kleen
2006-04-01 6:50 ` Nathan Scott
2006-05-26 5:00 ` [PATCH 0/2]Define ext3 in-kernel filesystem block types and extend " Mingming Cao
2006-05-26 18:08 ` Andrew Morton
2006-05-30 17:55 ` Mingming Cao
2006-03-30 1:39 ` [RFC][PATCH 1/2]ext3 block allocation/reservation fixes to support 2**32 block numbers Mingming Cao
2006-03-30 1:39 ` [RFC][PATCH 2/2]Other ext3 in-kernel block number type fix " Mingming Cao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1144008802.29210.16.camel@localhost.localdomain \
--to=cmm@us.ibm.com \
--cc=Laurent.Vivier@bull.net \
--cc=akpm@osdl.org \
--cc=ext2-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sho@tnes.nec.co.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).