Basically keeps track of affected PGs
similar to how funciton _osd_out works
but instead of tracking up+acting set
we only care about acting. Also made
a minor change on the function pg_update:
we consider pg to be complete when it
is active and clean and nothing else.
Removed the variable "unmoved" since
If the pg wasn't moved, we shouldn't
have an event for it in the first place.
Signed-off-by: Kamoltat (Junior) Sirivadhna <ksirivad@redhat.com>
This is rather a template to build custom troubleshooters
for bitmap allocator using existing logs. Tool replays OSD
log to build allocator state that caused an issue.
Signed-off-by: Igor Fedotov <ifedotov@suse.com>
As by calling "ceph osd pool set <pool-name> pg_num", we set the
pg_num_target instead. Hence we should report pg_num_target as well
when invoked by the "ceph osd pool get <pool-name> pg_num" call.
I doubt an ideal fix would be exposing both the pg_num(*actual*) and
pg_num_target concepts to user, but for now I think we can stop here
and get some more feedback first.
Fixes: http://tracker.ceph.com/issues/40193
Signed-off-by: xie xingguo <xie.xingguo@zte.com.cn>
they were consumers of ceph::list::buffers(), and there is no need to
make them member functions of ceph::list, so move them into ceph::crypto
namespace. and update the unit test and ceph_dedup_tool.cc accordingly.
Signed-off-by: Kefu Chai <kchai@redhat.com>
prepare for extracting the digest methods from ceph::buffer::list, so we
can use them in a templated implementation.
Signed-off-by: Kefu Chai <kchai@redhat.com>
For OP_CREATE in bluestore mean node didn't exist, so skip search form kvdb.
This function merged in 22f73ba. But because compatible problem,
it revert in 491c254.
This commit fix the compatible problem
Signed-off-by: Jianpeng Ma <jianpeng.ma@intel.com>
When create Messenger, for client we should give different nonce to
make multi clients on the same host can work. Otherwise, server only
accept one connection.
Signed-off-by: Jianpeng Ma <jianpeng.ma@intel.com>
to use strict priority ordering.
The new "mclock_opclass/mclock_client" queue basically prioritizes
operations based on the class they belong to. The priority property
of an operation, if lower than a specific value (64, by default),
will get ignored and hence all operations from the same class will
be treated fairly in a FIFO fashion (but still limited by the total
IOPS or bandwidth available for the corresponding class).
To reduce the impact of performance, a more general strategy would be
enforcing some limitations on the IOPS or bandwidth for the background
recovery (or backfill) operation class. However, this way we'll end up
blocking client operations too if they are currently blocked by some
degraded objects which need to be recovered first.
We hereby grant recovery operations of this kind a higher priority
to force them to use strict priority ordering, which should still
be of significance once we switch to the new "mclock_opclass/mclock_client"
queue.
Signed-off-by: xie xingguo <xie.xingguo@zte.com.cn>
