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
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.
On Sun, 22 Oct 2006 01:57:36 +0200
"Linux Portal" <[email protected]> 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
On 10/22/06, Andrew Morton <[email protected]> wrote:
> On Sun, 22 Oct 2006 01:57:36 +0200
> "Linux Portal" <[email protected]> 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.
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
On 10/23/06, Theodore Tso <[email protected]> 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,
Linux Portal wrote:
> On 10/23/06, Theodore Tso <[email protected]> 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 <[email protected]>
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.