Re: [PATCH 2/9] sector_t format string

Andrew Morton
2006-08-10T16:54:55Z

On Thu, 10 Aug 2006 12:24:06 -0400
"John Stoffel" <john@stoffel.org> wrote:

> >>>>> "Roman" == Roman Zippel <zippel@linux-m68k.org> writes:
>
> Roman> If you force everyone to use 64bit sector numbers, I don't
> Roman> understand how you can claim "still working just fine on
> Roman> 32bit"? At some point ext4 is probably going to be the de
> Roman> facto standard, which very many people want to use, because it
> Roman> has all the new features, which won't be ported to ext2/3. So I
> Roman> still don't understand, what's so wrong about a little tuning
> Roman> in both directions?
>
> The problem as I see it, is that you want extents, but you don't want
> the RAM/DISK/ROM penalty of 64bit blocks, since embedded devices won't
> ever go past the existing ext3 sizes, right?

For ext3 on x86:

CONFIG_LBD=y:

box:/usr/src/25> size fs/jbd/jbd.o fs/ext3/ext3.o
text data bss dec hex filename
51076 8 32 51116 c7ac fs/jbd/jbd.o
87466 1020 4 88490 159aa fs/ext3/ext3.o

CONFIG_LBD=n:

box:/usr/src/25> size fs/jbd/jbd.o fs/ext3/ext3.o
text data bss dec hex filename
51133 8 32 51173 c7e5 fs/jbd/jbd.o
87679 1020 4 88703 15a7f fs/ext3/ext3.o

That's a grand total of 270 bytes of text saved. aka 0.19%.

We'll save four bytes in the inode (unlikely to save anything due to slab
packing).

We'll save 12 bytes against open-for-writing files due to
ext3_block_alloc_info shrinkage (unlikely to save anything due to kmalloc
size roundup).

IOW, unless I've missed something major, we're looking at a total saving of
around a 16th of a page. We can save more than that any day of the week by
going around and deleting some crap from somewhere. We can surely save
more than this by taming ext4's inlining frenzy.

I'd expect any runtime savings to be similarly modest.