On Nov 29, 2012, at 1:56 AM, Jim Klimov <jimkli...@cos.ru> 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.

Caching has nothing to do with QoS in this context. *All* modern
filesystems cache to RAM, otherwise they are unusable.

> 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.

Please read the papers on the ARC and how it deals with MFU and
MRU cache types. You can adjust these policies using the primarycache
and secondarycache properties at the dataset level.

> 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
> mechanism?

ZFS has a priority-based I/O scheduler that works at the DMU level.
However, there is no system call interface in UNIX that transfers
priority or QoS information (eg read() or write()) into the file system VFS
interface. So the grainularity of priority control is by zone or dataset.
 -- richard



zfs-discuss mailing list

Reply via email to