linux-kernel - Re: First benchmarks of the ext4 file system

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID:  <45456558.5070600@tmr.com>
Date:	Sun, 29 Oct 2006 21:37:12 -0500
From:	Bill Davidsen <davidsen@....com>
To:	linux-kernel@...r.kernel.org
Subject:  Re: First benchmarks of the ext4 file system

Linux Portal wrote:
> On 10/23/06, Theodore Tso <tytso@....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@....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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/