when the repair is carried out for a rack that stores information on the order of
Terabytes.
- +-------------+---------------------------+
- | plugin | total amount of disk IO |
- +=============+===========================+
- |jerasure,isa | k*S |
- +-------------+---------------------------+
- | clay | d*S/(d-k+1) = (k+m-1)*S/m |
- +-------------+---------------------------+
+ +-------------+---------------------------------------------------------+
+ | plugin | total amount of disk IO |
+ +=============+=========================================================+
+ |jerasure,isa | :math:`k S` |
+ +-------------+---------------------------------------------------------+
+ | clay | :math:`\frac{d S}{d - k + 1} = \frac{(k + m - 1) S}{m}` |
+ +-------------+---------------------------------------------------------+
where *S* is the amount of data stored on a single OSD undergoing repair. In the table above, we have
used the largest possible value of *d* as this will result in the smallest amount of data download needed
at a finer granularity termed as a sub-chunk. The number of sub-chunks within
a chunk for a Clay code is given by:
- sub-chunk count = q\ :sup:`(k+m)/q`, where q=d-k+1
+ sub-chunk count = :math:`q^{\frac{k+m}{q}}`, where :math:`q = d - k + 1`
During repair of an OSD, the helper information requested
from an available OSD is only a fraction of a chunk. In fact, the number
of sub-chunks within a chunk that are accessed during repair is given by:
- repair sub-chunk count = sub-chunk count / q
+ repair sub-chunk count = :math:`\frac{sub---chunk \: count}{q}`
Examples
--------
performance, it is helpful to read contiguous data. For this reason, it is suggested that
you choose stripe-size such that the sub-chunk size is sufficiently large.
-For a given stripe-size (that's fixed based on a workload), choose ``k``, ``m``, ``d`` such that::
+For a given stripe-size (that's fixed based on a workload), choose ``k``, ``m``, ``d`` such that:
- sub-chunk size = stripe-size / (k*sub-chunk count) = 4KB, 8KB, 12KB ...
+ sub-chunk size = :math:`\frac{stripe-size}{k sub-chunk count}` = 4KB, 8KB, 12KB ...
#. For large size workloads for which the stripe size is large, it is easy to choose k, m, d.
For example consider a stripe-size of size 64MB, choosing *k=16*, *m=4* and *d=19* will
Space efficiency is a ratio of data chunks to all ones in a object and
represented as k/(k+m).
-In order to improve space efficiency, you should increase k or decrease m.
+In order to improve space efficiency, you should increase k or decrease m:
-::
-
- space efficiency of SHEC(4,3,2) = 4/(4+3) = 0.57
+ space efficiency of SHEC(4,3,2) = :math:`\frac{4}{4+3}` = 0.57
SHEC(5,3,2) or SHEC(4,2,2) improves SHEC(4,3,2)'s space efficiency
Durability
placement groups per OSD to balance out resource usage, data
durability and distribution. If you have less than 50 OSDs, choosing
among the `preselection`_ above is best. For a single pool of objects,
-you can use the following formula to get a baseline::
+you can use the following formula to get a baseline
- (OSDs * 100)
- Total PGs = ------------
- pool size
+ Total PGs = :math:`\frac{OSDs \times 100}{pool \: size}`
Where **pool size** is either the number of replicas for replicated
pools or the K+M sum for erasure coded pools (as returned by **ceph
stepping from one power of two to another.
As an example, for a cluster with 200 OSDs and a pool size of 3
-replicas, you would estimate your number of PGs as follows::
+replicas, you would estimate your number of PGs as follows
- (200 * 100)
- ----------- = 6667. Nearest power of 2: 8192
- 3
+ :math:`\frac{200 \times 100}{3} = 6667`. Nearest power of 2: 8192
When using multiple data pools for storing objects, you need to ensure
that you balance the number of placement groups per pool with the
projects / ceph.git / commitdiff