linux-ext4 - Re: [Jfs-discussion] 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.01.0912241739160.3483@bogon.housecafe.de>
Date:	Thu, 24 Dec 2009 17:52:34 -0800 (PST)
From:	Christian Kujau <lists@...dbynature.de>
To:	tytso@....edu
cc:	Peter Grandi <pg_jf2@....for.sabi.co.UK>, xfs@....sgi.com,
	reiserfs-devel@...r.kernel.org, linux-ext4@...r.kernel.org,
	linux-btrfs@...r.kernel.org, jfs-discussion@...ts.sourceforge.net,
	ext-users <ext3-users@...hat.com>, linux-nilfs@...r.kernel.org
Subject: Re: [Jfs-discussion] benchmark results

On Thu, 24 Dec 2009 at 16:27, tytso@....edu wrote:
> If you don't do a "sync" after the tar, then in most cases you will be
> measuring the memory bandwidth, because data won't have been written

Well, I do "sync" after each operation, so the data should be on disk, but 
that doesn't mean it'll clear the filesystem buffers - but this doesn't 
happen that often in the real world too. Also, all filesystem were tested 
equally (I hope), yet some filesystem perform better than another - even 
if all the content copied/tar'ed/removed would perfectly well fit into the 
machines RAM.

> Another good example of well done file system benchmarks can be found
> at http://btrfs.boxacle.net

Thanks, I'll have a look at it and perhaps even integrate it in the 
wrapper script.

> benchmarks for a living.  Note that JFS and XFS come off much better
> on a number of the tests

Indeed, I was surpised to see JFS perform that good and XFS of course is 
one of the best too - I just wanted to point out that both of them 
are strangely slow at times (removing or creating many files) - not what I 
expected.

> --- and that there is a *large* number amount
> of variation when you look at different simulated workloads and with a
> varying number of threads writing to the file system at the same time.

True, the TODO list in the script ("different benchmark options") is in 
there for a reason :-)

Christian.
-- 
BOFH excuse #291:

Due to the CDA, we no longer have a root account.
--
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