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

Nate Diller
2006-08-01T01:25:27Z

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