The second arg for interval_set insert method is the inserting
interval lenth, while the end position was provided. It still
worked correctly, because the end position value is always larger
than the truncated length.
Signed-off-by: Mykola Golub <mgolub@suse.com>
We do not build for RHEL 6 and below, so "rhel == 7" is just as good, while
also avoiding the bug.
In addition, "rhel == 7" is the conditional we are using everywhere else in the
spec file for this purpose.
Fixes: https://tracker.ceph.com/issues/38810
Signed-off-by: Nathan Cutler <ncutler@suse.com>
The main purpose of the patch is to set 'ee' members only on EPOLL_CTL_MOD
path, deletion path does not requie any of the members set.
This will make code a bit better.
Signed-off-by: Roman Penyaev <rpenyaev@suse.de>
When new fd is being added to epoll fd EPOLLET (edge triggered) flag
is set, i.e. we assume that in and out works in edge triggered mode.
But on del_event(), when eventually epoll_ctl(EPOLL_CTL_MOD) is
invoked, EPOLLET flag is cleared, i.e. level triggered mode is
enabled.
Do not lose EPOLLET.
Signed-off-by: Roman Penyaev <rpenyaev@suse.de>
mgr/orchestrator: Remove `(add|test|remove)_stateful_service_rule`
Reviewed-by: Jeff Layton <jlayton@redhat.com>
Reviewed-by: Juan Miguel Olmo Martínez <jolmomar@redhat.com>
Reviewed-by: Tim Serong <tserong@suse.com>
MPGStats::had_map_for was added back in 7844d0e5, the last release that
still checks this field was mimic -- monitor sends OSD incremental
osdmaps if the monitor finds that the pg_stats' had_map_for is greater
than 30 and the epoch is less than that of latest osdmap.
but DaemonServer as the new consumer of MPGStats does not check
had_map_for anymore -- it simply updates the cluster state with the
pg_stats reported by OSD. and we directs OSD to mgr for sending pg_stats
since mimic. so, we can safely drop the support of had_map_for in
octopus, as it has been 2 releases.
Signed-off-by: Kefu Chai <kchai@redhat.com>
the synchronous wait() call uses std::condition_variable::wait_for(),
which is based on std::chrono::steady_clock. this changes the asynchronous
waits (along with timing in the unit test) to use that same clock
should resolve this test failure:
[ RUN ] ReshardWait.wait_yield
/home/jenkins-build/build/workspace/ceph-pull-requests/src/test/rgw/test_rgw_reshard_wait.cc:78:
Failure
Expected: (wait_duration) <= (elapsed), actual: 0.01s vs 0.00835688s
[ FAILED ] ReshardWait.wait_yield (8 ms)
Signed-off-by: Casey Bodley <cbodley@redhat.com>
* refs/pull/26960/head:
ceph_release: nautilus is will be 'stable' for v14.2.0
Reviewed-by: Alfredo Deza <adeza@redhat.com>
Reviewed-by: Abhishek Lekshmanan <abhishek.lekshmanan@gmail.com>
The stress-split thrasher already had this off, but the ec variant did
not. We don't support ceph-objectstore-tool exports/imports between major
versions.
Fixes: http://tracker.ceph.com/issues/38294
Signed-off-by: Sage Weil <sage@redhat.com>
see PrimaryLogPG::do_request(), we check for
1. is_peered(), then
2. flushes_in_progress, then
3. is_active()
4. scrubber.is_chunky_scrub_active() && write_blocked_by_scrub(head) in
PrimaryLogPG::do_op() which is called by PrimaryLogPG::do_request().
while in PrimaryLogPG::on_change()
we requeue the waiting request in the reversed order,
1. requeue_ops(waiting_for_peered);
2. requeue_ops(waiting_for_flush);
3. requeue_ops(waiting_for_active);
so the comment is not in sync with the code. in this change,
"waiting_for_active" and "waiting_for_flush" are transposed in the
comment explaining blocked request wait lists.
also, sync the pre-conditions of "waiting_for_peered" and
"waiting_for_flush" with "PrimaryLogPG::do_request()"
Signed-off-by: Kefu Chai <kchai@redhat.com>
These checks don't work when the cluster is newer than mimic.
Instead, let's just try not to run this test on a pre-mimic cluster.
Signed-off-by: Sage Weil <sage@redhat.com>
It was a flawed check, since it would fail for anything newer than
luminous. And in any case, we don't need it anymore.
Signed-off-by: Sage Weil <sage@redhat.com>
Normally we let the mgr control pgp_num_actual for us in a nice, safe, controlled
way. However, it is very conservative, and only makes changes if all PGs are healthy.
There are situations where the user wants to be move aggressive than this.
For example, if you have a pool with many PGs (say, 4096) and set pg_num_target to a
small number like 4, the mgr will adjust pgp_num way down. This can lead to an OSD
hitting max_pgs_per_osd. That prevents the PGs from being active+clean, however,
which prevents the mgr adjusting pgp_num back up even if the user sets the target to
a larger value.
This patch lets the user directly adjust pgp_num_actual. Note that we still do
not expose access to pg_num_actual, since there are much stricter conditions that
must be true in order to safely make downward adjustments.
Signed-off-by: Sage Weil <sage@redhat.com>
fullmap.0 is an empty map, it used when we try to rebase inc_map.1.
Signed-off-by: chunmei Liu <chunmei.liu@intel.com>
Signed-off-by: Kefu Chai <kchai@redhat.com>
