On 7/31/06, Matthias Andree <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
