Describe the rotorvector property in zpool.8.

man/man8/zpool.8

@@ -751,6 +751,74 @@ This property can also be referred to by its shortened name, \fBlistsnaps\fR.
 .sp .6
 .RS 4n
 The current on-disk version of the pool. This can be increased, but never decreased. The preferred method of updating pools is with the "\fBzpool upgrade\fR" command, though this property can be used when a specific version is needed for backwards compatibility. Once feature flags are enabled on a pool this property will no longer have a value.
+.RE
+
+.sp
+.ne 2
+.na
+\fB\fBrotorvector\fR=(unset) | \fIconfiguration\fR\fR
+.ad
+.sp .6
+.RS 4n
+Controls to which \fBvdev\fR each written block is allocated.  Primary use of this option is to allocate meta-data on faster devices (such as SSDs), while allocating all other (bulk) data on cheaper devices (HDDs).  Can also be used to allocate small data blocks on faster devices.
+.sp
+With this option set, all \fBvdev\fRs are assigned to an allocaton category (given a rotor vector index).  The categories should be ordered from fast to slow, which would (presumably) also correspond to an ordering from expensive to cheap.  Associated with each category is also a description of what kind of data blocks it accepts.  (Kind is currently \fBdata\fR or \fBmetadata\fR, and its size.)  Each written block is allocated to a \fBvdev\fR of the first (fastest) category that accepts it.
+.sp
+If a category is completely full, a slower category will be used.  And as a last resort, faster categories are used.  Note however that generally the entire pool will be reported as full and not allow further user writes before any category becomes completely full.  The rationale is that rather than filling up expensive fast \fBvdev\fRs with some last bulk data when a pool is close to full, the pool shall act as full when the cheaper categories are full.  Likewise, this strategy avoids storing metadata on slow \fBvdev\fRs, which would hamper performance for this metadata even after the full condition of the faster categories has been resolved.
+.sp
+The configuration is a semicolon-separated list of (up to 5) categories:
+.sp
+[\fIspec\fR\fB<=\fR\fIlimit\fR]\fB;\fR\fIspec\fR\fR
+.sp 
+where \fIspec\fR is a comma-separated list of \fIvdev-guid\fRs and generic type
+specifiers: \fBssd\fR, \fBssd-raidz\fR, \fBmixed\fR, \fBhdd\fR, and \fBhdd-raidz\fR.  (\fBmixed\fR denotes mirrors vith both ssd and hdd drives.)  Expecilitly assigned \fBvdev\fR \fIguid\fRs takes precendece over generic assignments.  Any \fBvdev\fRs which are not matched by \fIguid\fR or the generic types are placed in the last category.
+.sp
+\fIlimit\fR is a comma-separated list of block size limits in KiB that
+are allowed within the category.  To specify a limit for metadata, add
+\fBmeta:\fR before the value.  The last category has no limit.
+.sp
+Examples:
+.sp
+.ne 2
+.na
+\fB\fBssd<=4;mixed<=64;123,hdd\fR\fR
+.ad
+.RS 4n
+Blocks less than 4 KiB are allocated on ssd-only \fBvdev\fRs (mirror or not). Allocations less than 64 KiB end up on ssd/hdd mixed ). Other allocations end up on
+remaining disks. 123 represents av vdev guid (placing an explicit
+vdev-guid in the last rotor makes little sense though).
+.RE
+
+
+    Example:
+
+    ssd<=4;mixed<=64;123,hdd
+
+    Here, allocations less than 4 kbytes are allocated on ssd-only vdev(s)
+    (mirror or not). Allocations less than 64 kbytes end up on ssd/hdd mixed
+    (mirrors, such raidz makes no sense). Other allocations end up on
+    remaining disks. 123 represents av vdev guid (placing an explicit
+    vdev-guid in the last rotor makes little sense though).
+
+    Example:
+
+    zpool set "rotorvector=123,ssd<=meta:4;mixed<=64;hdd" <poolname>
+
+    Pure ssd (and explicit vdev guid 123) drive takes metadata <= 4 kB.
+    Mixed (mirror ssd+hdd) takes data (or metadata) <= 64 kB.
+    Others (hdd) takes remainder.
+
+    Example II:
+
+    zpool set "rotorvector=ssd<=meta:128,4;mixed<=64;123,hdd" <poolname>
+
+    Pure ssd (and explicit vdev guid 123) drive takes metadata <= 128 kB
+    and data <= 4 kB.
+    Mixed (mirror) takes data <= 64 kB (this metadata already taken by ssd).
+    Others (hdd) takes remainder.
+
+
+
 .RE
 
 .SS "Subcommands"