On 2012-11-29 10:56, Jim Klimov wrote:
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.

On a side note, I'm now revisiting old ZFS presentations collected
over the years, and one suggested as "TBD" statements the ideas
that metaslabs with varying speeds could be used for specific
tasks, and not only to receive the allocations first so that a new
pool would perform quickly. I.e. "TBD: Workload specific freespace
selection policies".

Say, I create a new storage box and lay out some bulk file, backup
and database datasets. Even as they are receiving their first bytes,
I have some idea about the kind of performance I'd expect from them -
with QoS per dataset I might destine the databases to the fast LBAs
(and smaller seeks between tracks I expect to use frequently), and
the bulk data onto slower tracks right from the start, and the rest
of unspecified data would grow around the middle of the allocation

These types of data would then only "creep" onto the less fitting
metaslabs (faster for bulk, slower for DB) if the target ones run
out of free space. Then the next-best-fitting would be used...

This one idea is somewhat reminiscent of hierarchical storage
management, except that it is about static allocation at the
write-time and takes place within the single disk (or set of
similar disks), in order to warrant different performance for
different tasks.


zfs-discuss mailing list

Reply via email to