EXT2_MAX_BLOCK_LOG_SIZE increase?

EXT2_MAX_BLOCK_LOG_SIZE increase?

[Grant Grundler]

Ted,
Can you bump up the EXT2_MAX_BLOCK_LOG_SIZE value?

willy tells me you are the maintainer of ext2 tools.
In lib/ext2fs/ext2_fs.h (debian e2fsprogs package):

- #define EXT2_MAX_BLOCK_LOG_SIZE         13      /* 8192 */
+ #define EXT2_MAX_BLOCK_LOG_SIZE         16      /* 64K */

ia64 supports 4/8/16/64k page sizes.
I'll post re-aim-7 benchmark runs using ext2 w/16k block on lkml.

thanks,
grant

Grant Grundler
iod00d@hp.com
grundler@parisc-linux.org

Re: EXT2_MAX_BLOCK_LOG_SIZE increase?

[Theodore Ts'o]

On Wed, Jul 30, 2003 at 09:38:40AM -0600, Grant Grundler wrote:
> Ted,
> Can you bump up the EXT2_MAX_BLOCK_LOG_SIZE value?
> 
> willy tells me you are the maintainer of ext2 tools.
> In lib/ext2fs/ext2_fs.h (debian e2fsprogs package):
> 
> - #define EXT2_MAX_BLOCK_LOG_SIZE         13      /* 8192 */
> + #define EXT2_MAX_BLOCK_LOG_SIZE         16      /* 64K */
> 
> ia64 supports 4/8/16/64k page sizes.
> I'll post re-aim-7 benchmark runs using ext2 w/16k block on lkml.
> 

I'd be interested in benchmark runs comparing 4k, 8k, 16k, 32k, and
64k, if you would, please.  

Was any patches necessary for the ia64 kernel before the block sizes >
8k started working for you?


						- Ted

Re: EXT2_MAX_BLOCK_LOG_SIZE increase?

[Grant Grundler]

On Wed, Jul 30, 2003 at 02:21:02PM -0400, Theodore Ts'o wrote:
> I'd be interested in benchmark runs comparing 4k, 8k, 16k, 32k, and
> 64k, if you would, please.  

vary kernel page size or ext2 block size or both together?
re-aim-7 benchmark or something different?
(and please don't say "dbench" :^)

32k is not possible in the kernel. Could use 64k.

Two of the re-aim-7 (aka osdl-aim-7) results (4k and 16k) are posted
on lkml and I can resend if I get a private request.

I'm going to be in transit or offline alot of the next 2 weeks.
Not likely I'll be able to generate the additional numbers.
Other volunteers?
I'm happy to share the s3kr3T osdl-aim-7 sauce recipe.

And I'd really just like to prove if VMERGE code in the BIO layer
is useful or not. I've concluded it's not useful for 53c1030.
I think it's more interesting to measure 53c1010.

> Was any patches necessary for the ia64 kernel before the block sizes >
> 8k started working for you?

nope. :^)
Just twiddle the CONFIG_IA64_PAGE_SIZE_* parameters if one wants 64KB.
16KB is the default.

thanks,
grant

Re: EXT2_MAX_BLOCK_LOG_SIZE increase?

[Grant Grundler]

On Wed, Jul 30, 2003 at 11:51:33AM -0700, Grant Grundler wrote:
> 32k is not possible in the kernel. Could use 64k.

Ted,
To clarify, I meant kernel page size, not block size.

grant

Re: EXT2_MAX_BLOCK_LOG_SIZE increase?

[Theodore Ts'o]

On Wed, Jul 30, 2003 at 11:51:33AM -0700, Grant Grundler wrote:
> On Wed, Jul 30, 2003 at 02:21:02PM -0400, Theodore Ts'o wrote:
> > I'd be interested in benchmark runs comparing 4k, 8k, 16k, 32k, and
> > 64k, if you would, please.  
> 
> vary kernel page size or ext2 block size or both together?

Well, varying both, actually.  I'm curious whether it is a large block
size, or block_size = page_size that really matters.

The reason why I care is because it makes a difference as to what the
default mke2fs hueristics should be.  (By the way, even without
hacking e2fsprogs at all, if you use mke2fs -Tlargefile, it will use a
default blocksize = pagesize, and this currently bypasses the
EXT2_MAX_BLOCK_SIZE check entirely.)  The question is whether or not
this is really optimal behaviour....

It probably is, but it would be good to know for soon.  

> re-aim-7 benchmark or something different?
> (and please don't say "dbench" :^)

Dbench is a silly benchmark....

> 32k is not possible in the kernel. Could use 64k.

> > Was any patches necessary for the ia64 kernel before the block sizes >
> > 8k started working for you?
> 
> nope. :^)
> Just twiddle the CONFIG_IA64_PAGE_SIZE_* parameters if one wants 64KB.
> 16KB is the default.

Good to know, thanks.

						- Ted

Re: EXT2_MAX_BLOCK_LOG_SIZE increase?

[Grant Grundler]

On Wed, Jul 30, 2003 at 05:15:33PM -0400, Theodore Ts'o wrote:
> Well, varying both, actually.  I'm curious whether it is a large block
> size, or block_size = page_size that really matters.

sorry - I'm not sure I understand the distinction.
My take is a larger page size (ie 16k is better than 4k).
It looks like ext2 uses PAGE_SIZE to size it's IOs:

> The reason why I care is because it makes a difference as to what the
> default mke2fs hueristics should be.

My gut feeling is native page_size and then warn about compatibility
if that is > 4k.

> (By the way, even without
> hacking e2fsprogs at all, if you use mke2fs -Tlargefile, it will use a
> default blocksize = pagesize, and this currently bypasses the
> EXT2_MAX_BLOCK_SIZE check entirely.)  The question is whether or not
> this is really optimal behaviour....

re-aim-7 seems to think so.
I sent you privately the 4k and 16k pagesize runs that I had posted earlier.

grant

Re: EXT2_MAX_BLOCK_LOG_SIZE increase?

[Grant Grundler]

On Wed, Jul 30, 2003 at 08:35:41PM -0700, Grant Grundler wrote:
> It looks like ext2 uses PAGE_SIZE to size it's IOs:

sorry..hit send key a bit too fast...here's the bit of code I wanted
to quote:
fs/ext2/ialloc.c:       inode->i_blksize = PAGE_SIZE;   /* This is the optimal IO size (for stat), not the fs block size */

Does this really mean ext2 tries to do IO in page size chunks?
I'll assume it does (usually) unless told otherwise since 4k vs 16k
block size on 16k page size gave basically the same result.

grant