reset history_les_bound if we set max_last_epoch_started_found with
shard's local-les. otherwise it'd be misleading to show
"peering_blocked_by_history_les_bound" in the output of "pg query" if a
pg is stuck in incomplete and/or peering, and the best shard is not
chosen based on the history.les .
Signed-off-by: Kefu Chai <kchai@redhat.com>
unit_test_framework is an alias of test, and Boost::test is only
necessary if seastar's tests are built. but SEASTAR_ENABLE_TESTS is
reset by us, so drop tests/unit_test_framework here.
Signed-off-by: Kefu Chai <kchai@redhat.com>
Since we only support Jewel and later releases, which both support
object-map and fast-diff, enabling/disabling object-map should always
enable/disable fast-diff.
Signed-off-by: Mao Zhongyi <maozy.fnst@cn.fujitsu.com>
If you leave off the second part of the life expectancy interval, it means
"more than". e.g., Setting only the first time to today + one month would
mean "more than one month".
Signed-off-by: Sage Weil <sage@redhat.com>
1- Change terminology from "predicted failure" to "life expectancy", which
has a more intuitive meaning.
2- Change from an expected time stamp to a range. Any expectancy has an
inherent uncertainty, so a single time is not meaningful. Instead, express
as a range, e.g. "4-6 weeks from now", where we record the min and max
date as well as when the prediction was made.
This is still a bit awkward, but I'm not sure what is better. It will
always be a bit awkward to express uncertainty since in precise terms it
is probably a 90% confidence interval or something.
Signed-off-by: Sage Weil <sage@redhat.com>
For JSON ls* commands, dump the full device metadata.
For plain commands, dump tables with useful information.
This is nicer for humans and jq-users, less friendly for those who want
to write a simple bash loop.
Signed-off-by: Sage Weil <sage@redhat.com>
If you're looking at a specific device by its unique id, it's also nice
to know what device name (sdb etc) it is and on which host.
Signed-off-by: Sage Weil <sage@redhat.com>
Prune DeviceState when there is no persistent metadata and no daemon
references. Load persistent metadata from config-key.
Signed-off-by: Sage Weil <sage@redhat.com>
The print information of mstop.sh is as following:
entity=osd pid=16347 name=osd.1
kill 16347...kill 16347...16462
pid=16462
entity=osd pid=16462 name=osd.2
kill 16462...kill 16462...[root@maozy build]#
It's not clear enough, so fix it.
Signed-off-by: Mao Zhongyi <maozy.fnst@cn.fujitsu.com>
Angular 6 introduced a new way to define where a service should be provided,
which helps during the build of the project.
Signed-off-by: Tiago Melo <tmelo@suse.com>
mgr/dashboard: Reset settings to their default values
Reviewed-by: Ricardo Dias <rdias@suse.com>
Reviewed-by: Tatjana Dehler <tdehler@suse.com>
Reviewed-by: Volker Theile <vtheile@suse.com>
Add REST endpoint /admin/metadata/user?myself to get the metadata of the user that is used to sign the request.
See feature request https://tracker.ceph.com/issues/24335.
Signed-off-by: Volker Theile <vtheile@suse.com>
vstart no longer supports -r option after commit 8dcf8d6e,
but it is not cleaned from mstart, so drop it.
Signed-off-by: Mao Zhongyi <maozy.fnst@cn.fujitsu.com>
This fix is analogous to d5a3ae6008. As of
84a1984b7c we set query_epoch to a lower
value reliably, but we need to encode the latest epoch for pre-nautilus
OSDs because they do not set last_peering_epoch reliably and havin a lower
query_epoch will cause them to discard this message.
Signed-off-by: Sage Weil <sage@redhat.com>
Clean the in_progess and shard_to_read_map when the read op is complete,
to prevent memory leak and primary osd crash.
Signed-off-by: xiaofei cui <cuixiaofei@sangfor.com>
In commit 8c8944b2c4 we fixed one narrow race
and introduced a new (probably less narrow) one:
A: put shared blob foo, nref = 0, start removing self from set
B: open_shared_blob -> lookup gets nullptr (nref==null), creates a new shared blob
B: takes lock, sets sb_map[sbid] = newblob
A: gets lock, erases sb_map[sbid]
B: open_shared_blob -> lookup gets null, creates another new shared blob
Fix by only removing the sb_map entry for the nref=0 sb if it still points
to us. If it doesn't, that means some new blob has shown up in its place.
Fixes: http://tracker.ceph.com/issues/24319
Signed-off-by: Sage Weil <sage@redhat.com>
If p is i->second.end(), we do want to back up a position, but we
shouldn't dereference p for p->first.
Fixes: http://tracker.ceph.com/issues/24486
Signed-off-by: Sage Weil <sage@redhat.com>