>>>>> "jc" == Jake Caferilla <j...@tanooshka.com> writes:
jc> But remember, this example system, has massive parallel
jc> scalability.
jc> I issue 2 read requests, both read requests return after 1
jc> minute.
yeah, it's interesting to consider overall software stacks that might
have unnecessary serialization points.
For example, Postfix will do one or two fsync()'s per mail it receives
from the Interent into its internal queue, but I think it can be
working on receiving many mails at once, all waiting on fsync's
together. If the filesystem stack pushes these fsync's all the way
down to the disk and serializes them, you'll only end up with a few
parallel I/O transactions open, because almost everything postfix
wants to do is ``write, sync, let me know when done.''
OTOH, if you ran three instances of Postfix on the same single box
with three separate queue diectories on three separate
filesystems/zpools, inside zones for example, and split the mail load
among them using MX records or a load balancer, you might through this
ridiculous arrangement increase the parallelism of I/O reaching the
disk even on a system that serializes fsync's.
but if ZFS is smart enough to block several threads on fsync at once,
batch up their work to a single ZIL write-and-sync, then the
three-instance scheme will have no benefit.
anyway, though, I do agree it makes sense to quote ``latency'' as the
write-and-sync latency, equivalent to a hard disk with the write cache
off, and if you want to tell a story about how much further you can
stretch performance through parallelism, quote ``sustained write
io/s''. I don't think it's as difficult to quantify write performance
as you make out, and obviuosly hard disk vendors are already
specifying in this honest way otherwise their write latency numbers
would be stupidly low, but it sounds like SSD vendors are sometimes
waving their hands around ``oh it's all chips anyway we didn't know
what you MEANT it's AMBIGUOUS is that a rabbit over there?'' giving
dishonest latency numbers. Latency numbers for writes that will not
survive power loss are *MEANINGLESS*. period. And that is worth
complaining about.
pgpyNHH4IuLbZ.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
