First benchmarks of the ext4 file system

First benchmarks of the ext4 file system

[Linux Portal]

ext4 is 20 percent faster writer than ext3 or reiser4, probably thanks
to extents and delayed allocation. On other tests it is either
slightly faster or slightly slower. reiser4 comes as a nice surprise,
winning few benchmarks. Both are very stable, no errors during
testing.

http://linux.inet.hr/first_benchmarks_of_the_ext4_file_system.html

Re: First benchmarks of the ext4 file system

[Alistair John Strachan]

On Sunday 22 October 2006 00:57, Linux Portal wrote:
> ext4 is 20 percent faster writer than ext3 or reiser4, probably thanks
> to extents and delayed allocation. On other tests it is either
> slightly faster or slightly slower. reiser4 comes as a nice surprise,
> winning few benchmarks. Both are very stable, no errors during
> testing.
>
> http://linux.inet.hr/first_benchmarks_of_the_ext4_file_system.html

If you get a chance, some similar benchmarks including other major filesystems 
like JFS, XFS and ReiserFS3 would be nice. People keep using the same old 
results but don't realise performance of Linux filesystems changes from 
kernel to kernel..

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.

Re: First benchmarks of the ext4 file system

[Andrew Morton]

On Sun, 22 Oct 2006 01:57:36 +0200
"Linux Portal" <linportal@gmail.com> wrote:

> ext4 is 20 percent faster writer than ext3 or reiser4, probably thanks
> to extents and delayed allocation. On other tests it is either
> slightly faster or slightly slower. reiser4 comes as a nice surprise,
> winning few benchmarks. Both are very stable, no errors during
> testing.
> 
> http://linux.inet.hr/first_benchmarks_of_the_ext4_file_system.html

ext4 doesn't implement delayed allocation (yet).

I made some observations regarding comparative benchmarking of filesystems
when releasing 2.6.19-rc1-mm1.  They seem to have been ignored ;)  See

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc1/2.6.19-rc1-mm1/announce.txt

Re: First benchmarks of the ext4 file system

[Linux Portal]

On 10/22/06, Andrew Morton <akpm@osdl.org> wrote:
> On Sun, 22 Oct 2006 01:57:36 +0200
> "Linux Portal" <linportal@gmail.com> wrote:
>
> > ext4 is 20 percent faster writer than ext3 or reiser4, probably thanks
> > to extents and delayed allocation. On other tests it is either
> > slightly faster or slightly slower. reiser4 comes as a nice surprise,
> > winning few benchmarks. Both are very stable, no errors during
> > testing.
> >
> > http://linux.inet.hr/first_benchmarks_of_the_ext4_file_system.html
>
> ext4 doesn't implement delayed allocation (yet).
>
> I made some observations regarding comparative benchmarking of filesystems
> when releasing 2.6.19-rc1-mm1.  They seem to have been ignored ;)  See
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc1/2.6.19-rc1-mm1/announce.txt
>
>

Yeah, and because of this: "Although this doesn't seem to make much
difference with ext3" which is what I observed, too, in some other
benchmarks.

Re: First benchmarks of the ext4 file system

[Theodore Tso]

On Sun, Oct 22, 2006 at 01:57:36AM +0200, Linux Portal wrote:
> ext4 is 20 percent faster writer than ext3 or reiser4, probably thanks
> to extents and delayed allocation. On other tests it is either
> slightly faster or slightly slower. reiser4 comes as a nice surprise,
> winning few benchmarks. Both are very stable, no errors during
> testing.

As Andrew has already pointed out, we don't have delayed allocation
merged in into the -mm tree yet.  If you have the
time/energy/interest, a very useful thing that would very much help
the filesystem developers of all filesystems to do would be to
automated your tesitng enough that you can do these tests on a
frequent basis, both to track regressions caused by changes in other
parts of the kernel, as well we to see what happens as various bits of
functionality get added to the filesystem.  This of course can become
an arbitrarily a huge amount of work, as you add more filesystems and
benchmarks, but it's the sort of thing which is incredibly useful
especially if the hardware is held constant across a large number of
filesystems, workloads/benchmarks, and kernel versions.  

Regards,

						- Ted

Re: First benchmarks of the ext4 file system

[Linux Portal]

On 10/23/06, Theodore Tso <tytso@mit.edu> wrote:
> On Sun, Oct 22, 2006 at 01:57:36AM +0200, Linux Portal wrote:
> > ext4 is 20 percent faster writer than ext3 or reiser4, probably thanks
> > to extents and delayed allocation. On other tests it is either
> > slightly faster or slightly slower. reiser4 comes as a nice surprise,
> > winning few benchmarks. Both are very stable, no errors during
> > testing.
>
> As Andrew has already pointed out, we don't have delayed allocation
> merged in into the -mm tree yet.

OK.

> If you have the
> time/energy/interest, a very useful thing that would very much help
> the filesystem developers of all filesystems to do would be to
> automated your tesitng enough that you can do these tests on a
> frequent basis, both to track regressions caused by changes in other
> parts of the kernel, as well we to see what happens as various bits of
> functionality get added to the filesystem.  This of course can become
> an arbitrarily a huge amount of work, as you add more filesystems and
> benchmarks, but it's the sort of thing which is incredibly useful
> especially if the hardware is held constant across a large number of
> filesystems, workloads/benchmarks, and kernel versions.
>

I agree completely. That was my original idea, to prepare some setup for
thorough testing, but I soon discovered that would really be a huge project,
because of so many parameters involved.

So, at this time, I just satisfied my curiosity ;) with few simple tests of the
early version of ext4. We'll see what the future brings (how much free
time, in the first place ;)).

Best regards,

Re: First benchmarks of the ext4 file system

[Bill Davidsen]

Linux Portal wrote:
> On 10/23/06, Theodore Tso <tytso@mit.edu> wrote:
>> On Sun, Oct 22, 2006 at 01:57:36AM +0200, Linux Portal wrote:
>> > ext4 is 20 percent faster writer than ext3 or reiser4, probably thanks
>> > to extents and delayed allocation. On other tests it is either
>> > slightly faster or slightly slower. reiser4 comes as a nice surprise,
>> > winning few benchmarks. Both are very stable, no errors during
>> > testing.
>>
>> As Andrew has already pointed out, we don't have delayed allocation
>> merged in into the -mm tree yet.
> 
> OK.
> 
>> If you have the
>> time/energy/interest, a very useful thing that would very much help
>> the filesystem developers of all filesystems to do would be to
>> automated your tesitng enough that you can do these tests on a
>> frequent basis, both to track regressions caused by changes in other
>> parts of the kernel, as well we to see what happens as various bits of
>> functionality get added to the filesystem.  This of course can become
>> an arbitrarily a huge amount of work, as you add more filesystems and
>> benchmarks, but it's the sort of thing which is incredibly useful
>> especially if the hardware is held constant across a large number of
>> filesystems, workloads/benchmarks, and kernel versions.
>>
> 
> I agree completely. That was my original idea, to prepare some setup for
> thorough testing, but I soon discovered that would really be a huge 
> project,
> because of so many parameters involved.

I think the memory size is likely to make a substantial difference as 
well, particularly at the small end where caching space gets limited.

I agree, as the test gets better by adding parameters it gets slower, 
takes more human time, and the results get harder to understand. 
Particularly when the answer to most of the "which is faster" questions 
becomes "it depends."

I ran into this with resp2 (application response after a sleep in a 
loaded system), to the point where I stopped working on the project.

-- 
Bill Davidsen <davidsen@tmr.com>
   Obscure bug of 2004: BASH BUFFER OVERFLOW - if bash is being run by a
normal user and is setuid root, with the "vi" line edit mode selected,
and the character set is "big5," an off-by-one errors occurs during
wildcard (glob) expansion.