crushtool is a utility that lets you create, compile, decompile
and test CRUSH map files.

CRUSH is a pseudo-random data distribution algorithm that efficiently
maps input values (which, in the context of Ceph, correspond to Placement
Groups) across a heterogeneous, hierarchically structured device map.
The algorithm was originally described in detail in the following paper
(although it has evolved some since then):

will perform a dry run of a CRUSH mapping for a range of input
values [--min-x,--max-x] (default [0,1023]) which can be
thought of as simulated Placement Groups. See below for a more
detailed explanation.

Unlike other Ceph tools, crushtool does not accept generic options
such as –debug-crush from the command line. They can, however, be
provided via the CEPH_ARGS environment variable. For instance, to
silence all output from the CRUSH subsystem:

The test mode will use the input crush map ( as specified with -i
map ) and perform a dry run of CRUSH mapping or random placement
(if –simulate is set ). On completion, two kinds of reports can be
created.
1) The –show-… option outputs human readable information
on stderr.
2) The –output-csv option creates CSV files that are
documented by the –help-output option.

Note: Each Placement Group (PG) has an integer ID which can be obtained
from cephpgdump (for example PG 2.2f means pool id 2, PG id 32).
The pool and PG IDs are combined by a function to get a value which is
given to CRUSH to map it to OSDs. crushtool does not know about PGs or
pools; it only runs simulations by mapping values in the range
[--min-x,--max-x].

shows that rule 1 which is named metadata successfully
mapped 1024 values to result size == 5 devices when trying
to map them to num_rep 5 replicas. When it fails to provide the
required mapping, presumably because the number of tries must
be increased, a breakdown of the failures is displayed. For instance:

Creates CSV files (in the current directory) containing information
documented by –help-output. The files are named after the rule
used when collecting the statistics. For instance, if the rule
: ‘metadata’ is used, the CSV files will be:

metadata-absolute_weights.csvmetadata-device_utilization.csv...

The first line of the file shortly explains the column layout. For
instance:

The build mode will generate hierarchical maps. The first argument
specifies the number of devices (leaves) in the CRUSH hierarchy. Each
layer describes how the layer (or devices) preceding it should be
grouped.

Each layer consists of:

bucket(uniform|list|tree|straw)size

The bucket is the type of the buckets in the layer
(e.g. “rack”). Each bucket name will be built by appending a unique
number to the bucket string (e.g. “rack0”, “rack1”…).

The second component is the type of bucket: straw should be used
most of the time.

The third component is the maximum size of the bucket. A size of zero
means a bucket of infinite capacity.

Suppose we have two rows with two racks each and 20 nodes per rack. Suppose
each node contains 4 storage devices for Ceph OSD Daemons. This configuration
allows us to deploy 320 Ceph OSD Daemons. Lets assume a 42U rack with 2U nodes,
leaving an extra 2U for a rack switch.

To reflect our hierarchy of devices, nodes, racks and rows, we would execute
the following: