Messages in this thread | | | Date | Mon, 31 Jul 2006 18:25:24 -0700 | From | "Nate Diller" <> | 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@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/
| |