Matthias Andree 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.
So you use a repacker. Nice thing about a repacker is, everyone has
downtime. Better to plan to be a little sluggish when you'll have
1/10th or 1/50th of the users than be MUCH slower all the time.
You're right, though, to ask the question:
TANSTAAFL, or how long the system can sustain such access patterns,
particularly if it gets under memory pressure and must move.
Anyone care to run some very long benchmarks?
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.
Oh, I'm curious -- do hard drives ever carry enough battery/capacitance
to cover their caches? It doesn't seem like it would be that
hard/expensive, and if it is done that way, then I think it's valid to
leave them on. You could just say that other filesystems aren't taking
as much advantage of newer drive features as Reiser :P
Anyway, remember that the primary tool of science is not logic. Logic
is the primary tool of philosophy. The primary tool of science is
observation.
Sorry, the only machines I could really run this on are about to be in
remote only mode for a couple weeks. I'm hesitant to hit them too hard.
-
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]