On RDMA, memlock should be unlimited. If it is not then
warn the user
issue: 973654
Change-Id: If1e07722aaca9df88714828ca3f7398a2504e262
Signed-off-by: Sarit Zubakov <saritz@mellanox.com>
Signed-off-by: Adir Lev <adirl@mellanox.com>
We're sure the only element type BitMapAreaLeaf aggregates is
BitMapZone. There is no business to go through vptrs and thus
prohibit compiler to inline in a method that is crucial for
overall performance of the BitMap allocator.
Signed-off-by: Radoslaw Zarzynski <rzarzynski@mirantis.com>
Looks like we only need two per node, since there is only one OSD per
node, and ceph-deploy wants two disks per OSD to account for the
journal.
Signed-off-by: Zack Cerza <zack@redhat.com>
Since commit 4e28f9e636 ("osd/OSDMap: clear osd_info, osd_xinfo on
osd deletion"), weight is set to IN when OSD is deleted. This changes
the result of applying an incremental for clients, not just OSDs.
Because CRUSH computations are obviously affected, pre-4e28f9e63644
servers disagree with post-4e28f9e63644 clients on object placement,
resulting in misdirected requests.
Fixes: http://tracker.ceph.com/issues/19119
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Run a mini cluster and verify that modifying the crushmap,
sending it to the cluster produces the intended effect.
Refs: http://tracker.ceph.com/issues/18943
Signed-off-by: Loic Dachary <ldachary@redhat.com>
The class qualifier is documented for devices and step take
only. Although it shows in the buckets and could be set by the user, it
would be very error prone to do so.
Refs: http://tracker.ceph.com/issues/18943
Signed-off-by: Loic Dachary <ldachary@redhat.com>
The device classes are implemented by modifying:
- the argument of step TAKE in rules
- cloning bucket trees when required by a rule step
This happens (via populate_classes):
- before compiling a rule step TAKE
When the crush map is encoded, the device class information is stored
with it, independently from the rules and the buckets, as a map of
classes for each device & bucket and a map of classes for each rule step
TAKE.
The extra buckets created but not used by any rule do not need to be
preserved and they are removed (via cleanup_classes):
- before decompilation
- after compilation
- after decoding
The client and daemons that are not aware of the device classes are
compatible because the crushmap modified with the new buckets is fully
functional. The invalid names used in the for the generated
buckets (bucket~class) can be CrushWrapper::decode by any existing
client because there is no verification of the name validity during
decoding. It can also be CrushWrapper::dump or CrushCompiler::decompile
via ceph osd dump or crushtool. It cannot, however, be compiled again
because CrushCompiler::compile will try to set the name with
CrushWrapper::set_item_name and it will fail with EINVAL because of the
~.
Fixes: http://tracker.ceph.com/issues/18943
Signed-off-by: Loic Dachary <ldachary@redhat.com>
