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]

Date:	Mon, 31 Jul 2006 18:25:24 -0700
From:	"Nate Diller" <nate.diller@...il.com>
To:	"Nate Diller" <nate.diller@...il.com>,
	"David Lang" <dlang@...italinsight.com>,
	"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
Cc:	"Matthias Andree" <matthias.andree@....de>
Subject: Re: Solaris ZFS on Linux [Was: Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion]

On 7/31/06, Matthias Andree <matthias.andree@....de> wrote:
> On Mon, 31 Jul 2006, Nate Diller wrote:
>
> > this is only a limitation for filesystems which do in-place data and
> > metadata updates.  this is why i mentioned the similarities to log
> > file systems (see rosenblum and ousterhout, 1991).  they observed an
> > order-of-magnitude increase in performance for such workloads on their
> > system.
>
> It's well known that transactions that would thrash on UFS or ext2fs may
> have quieter access patterns with shorter strokes can benefit from
> logging, data journaling, whatever else turns seeks into serial writes.
> And then, the other question with wandering logs (to avoid double
> writes) and such, you start wondering how much fragmentation you get as
> the price to pay for avoiding seeks and double writes at the same time.
> TANSTAAFL, or how long the system can sustain such access patterns,
> particularly if it gets under memory pressure and must move. Even with
> lazy allocation and other optimizations, I question the validity of
> 3000/s or faster transaction frequencies. Even the 500 on ext3 are
> suspect, particularly with 7200/min (s)ATA crap. This sounds pretty much
> like the drive doing its best to shuffle blocks around in its 8 MB cache
> and lazily writing back.

it's not my benchmark, and you are right to be interested in more
information.  I would be curious about such things as write barrier
support, average/min/max transaction latency, and number of individual
threads, as well as hardware specs.  i also suspect that the numbers
would be altered a bit by testing with different I/O schedulers.
unfortunately, namesys has considered mongo a replacement for
postmark, so i cannot point to any more rigorous postmark tests ATM.

however, the results seem consistent with what i would expect for the
various file systems, with a significant number of threads.  after
all, even ext3 has the benefit of a disk scheduler, especially if
barriers are disabled

NATE
-
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/