linux-kernel - Re: Solaris ZFS on Linux [Was: Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion]

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: <Pine.LNX.4.63.0607311621360.14674@qynat.qvtvafvgr.pbz>
Date:	Mon, 31 Jul 2006 16:27:02 -0700 (PDT)
From:	David Lang <dlang@...italinsight.com>
To:	Nate Diller <nate.diller@...il.com>
cc:	Matthias Andree <matthias.andree@....de>,
	Adrian Ulrich <reiser4@...nkenlights.ch>,
	"Horst H. von Brand" <vonbrand@....utfsm.cl>, ipso@...ppymail.ca,
	reiser@...esys.com, lkml@...productions.com, jeff@...zik.org,
	tytso@....edu, linux-kernel@...r.kernel.org,
	reiserfs-list@...esys.com
Subject: Re: Solaris ZFS on Linux [Was: Re: the " 'official' point of view"
  expressed by kernelnewbies.org regarding reiser4 inclusion]

On Mon, 31 Jul 2006, Nate Diller wrote:

> 
> On 7/31/06, Matthias Andree <matthias.andree@....de> wrote:
>> Adrian Ulrich wrote:
>> 
>> > See also: http://spam.workaround.ch/dull/postmark.txt
>> >
>> > A quick'n'dirty ZFS-vs-UFS-vs-Reiser3-vs-Reiser4-vs-Ext3 'benchmark'
>> 
>> Whatever Postmark does, this looks pretty besides the point.
>
> why's that?  postmark is one of the standard benchmarks...
>
>> Are these actual transactions with the "D"urability guarantee?
>> 3000/s doesn't look too much like you're doing synchronous I/O (else
>> figures around 70/s perhaps 100/s would be more adequate), and cache
>> exercise is rather irrelevant for databases that manage real (=valuable)
>> data...
>
> Data:
>       204.62 megabytes read (8.53 megabytes per second)
>       271.49 megabytes written (11.31 megabytes per second)
>
> looks pretty I/O bound to me, 11.31 MB/s isn't exactly your latest DDR
> RAM bandwidth.  as far as the synchronous I/O question, Reiser4 in
> this case acts more like a log-based FS.  That allows it to "overlap"
> synchronous operations that are being submitted by multiple threads.

what you are missing is that apps that need to do lots of syncing (databases, 
mail servers) need to wait for the data to hit non-volitile media before the 
write is complete. this limits such apps to ~1 write per revolution of the 
platters (yes it's possible for a limited time to have multiple writes to 
different things happen to be on the same track, but the counter is the extra 
seek time needed between tracks)

so any benchmark that shows more transactions then the media has revolutions is 
highly suspect (now if you have battery-backed cache, or the equivalent you can 
blow past these limits)

on consumer (7200 rpm) drives this limit is 120/sec, on high-end drives (15Krpm 
scsi's this is 250/sec, and on the 10k rpm drives in the middle it's about 
166/sec.

David Lang
-
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/