On Thu, 29 Nov 2012, Jim Klimov wrote:
I've heard a claim that ZFS relies too much on RAM caching, but
implements no sort of priorities (indeed, I've seen no knobs to
tune those) - so that if the storage box receives many different
types of IO requests with different "administrative weights" in
the view of admins, it can not really throttle some IOs to boost
others, when such IOs have to hit the pool's spindles.
For example, I might want to have corporate webshop-related
databases and appservers to be the fastest storage citizens,
then some corporate CRM and email, then various lower priority
zones and VMs, and at the bottom of the list - backups.
AFAIK, now such requests would hit the ARC, then the disks if
needed - in no particular order. Well, can the order be made
"particular" with current ZFS architecture, i.e. by setting
some datasets to have a certain NICEness or another priority
QoS poses a problem. Zfs needs to write a transaction group at a
time. During part of the TXG write cycle, zfs does not return any
data. Zfs writes TXGs quite hard so they fill the I/O channel. Even
if one orders the reads during the TXG write cycle, zfs will not
return any data for part of the time.
There are really only a few solutions when resources might be limited:
1. Use fewer resources
2. Use resources more wisely
3. Add more resources until problem goes away
I think that current zfs strives for #1 and QoS is option #2. Quite
often, option #3 is effective because problems just go away once
enough resources are available.
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
zfs-discuss mailing list