Re: [RFC][PATCH 0/2]Extend ext3 filesystem limit from 8TB to 16TB

[Mingming Cao <cmm@us.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


-
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/