Re: [Ext2-devel] Re: [RFC][PATCH 0/2]Extend ext3 filesystem limitfrom 8TB to 16TB

[Laurent Vivier]

Le lun 10/04/2006 Ã 21:06, Mingming Cao a Ãcrit :
> On Mon, 2006-04-10 at 09:57 -0700, Mingming Cao wrote:
> > On Mon, 2006-04-10 at 11:11 +0200, Laurent Vivier wrote:
[...]
> Hi Laurent,
> 
> Just looked at your patch, shouldn't we use atomic_long_add() instead of
> atomic_long_set() to replace percpu_counter_mod()?

Yes, thank you.

> > I tried the other way -- I am trying to keep the percpu counter in use
> > in ext2/3 as much as possible.  I proposed a fix for percpu counter to
> > 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).
> > Will send the proposed patch out for review and comments soon.
> > 
> 
> 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.

I made some tests with iozone on 2 CPU hyperthreaded computer (= 4 CPUs,
Bull Express 5800 120 Lh), and it seems atomic_t is faster than
"percpu_counter". I'll try to make some tests on IBM x440 (8 CPUs, 16 if
hyperthreaded) with iozone and sysbench.
Moreover, I think percpu_counter uses a lot of memory...

> 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:(

Anyway, wa can't have a 64bit addressing space on a 32bit machine, so I
think, for the moment, it's not a problem.

Regards,
Laurent
-- 
Laurent Vivier
Bull, Architect of an Open World (TM)
http://www.bullopensource.org/ext4

Attachment: signature.asc
Description: Ceci est une partie de message=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=