linux-ext4 - Re: Ext4 without a journal: some benchmark results

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]

Date:	Thu, 8 Jan 2009 09:20:53 -0800
From:	Curt Wohlgemuth <curtw@...gle.com>
To:	Andreas Dilger <adilger@....com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: Ext4 without a journal: some benchmark results

Hi Andreas:

On Thu, Jan 8, 2009 at 5:03 AM, Andreas Dilger <adilger@....com> wrote:
> On Jan 07, 2009  11:29 -0800, Curt Wohlgemuth wrote:
>> Iozone was run with the following command line:
>>
>>       iozone -t (# threads) -s 2g -r 256k -I -T -i0 -i1 -i2
>>
>> I.e., throughput mode; 2GiB file; 256KiB buffer; O_DIRECT.  Tests were
>> limited to
>
> How much RAM is on the test system?  If the file size is only 2GB then
> it will likely fit into RAM, which is possibly why the performance
> numbers of all the filesystems is so close together.  The other possibility
> is that a single disk is the performance bottleneck and all of the
> filesystems can feed a single disk at a reasonable rate.

Indeed, the system was not memory-limited at all.  I've done some
playing around with how limiting memory affects random reads in iozone
with O_DIRECT, and have found that, as expected, ext4 is much less
affected than ext2.  I'm assuming this is because the metadata isn't
in the page cache, and the far larger number of metadata blocks on
ext2 than ext4 in this case causes a bigger hit on ext2.

If I generate numbers on a low-memory system, I'll post them here too.

Thanks,
Curt
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html