lkml.org 
[lkml]   [2006]   [Jul]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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@gmx.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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-08-01 03:27    [W:0.248 / U:1.680 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site