If any backend supports and implements statfs will extract the
stats from backend to show correct utilization in the status.
Signed-off-by: Varada Kari <varada.kari@sandisk.com>
Change the timeouts of the TEST_mon_add_to_single_mon tests to be 120
seconds. They have value to guard against blocking forever. The exact
timing does not matter as long as the operation completes.
When a timeout is too short, it will create false negatives when running
on slow machines. It could be argued that being too generous with
timeout in general may hide problems. But not in this specific case.
Signed-off-by: Loic Dachary <ldachary@redhat.com>
doc/rados/operations/add-or-rm-mons: simplify the steps to add a mon
Reviewed-by: Joao Eduardo Luis <joao@suse.de>
Reviewed-by: Sage Weil <sage@redhat.com>
Reviewed-by: Loic Dachary <ldachary@redhat.com>
According to the "quick ceph deploy" page, the default number of replicas in the Ceph configuration file is 3
Signed-off-by: Sasha Chuzhoy <sashac88@hotmail.com>
this change removes the step to "ceph mon add" before starting a new
monitor. because the existing leader will start an election at seeing
the MMonJoin message sent by the new joiner, after the quorum is
archieved, the monmap will be updated with the new monitor.
so, "ceph mon add" is not necessary to add a new monitor.
moreover, this command will be blocked until a new quorum is formed,
and the proposed monmap is accepted. but in case of adding a monitor
to a single monitor cluster, the leader will wait until at least two
of the monitors reply to it. apparently, this does not happen unless
the new monitor starts. so from the user's point of view, this
command hangs until timesout, if he/she does not start the mon.b
beforehand. but this is an expected behaviour.
so, to avoid this confusion and simplify the steps to add a new
monitor. we'd better simply remove this "ceph mon add" step.
Fixes: #12620
Signed-off-by: Kefu Chai <kchai@redhat.com>
It was possible that the same resize request could be sent twice
if a completed resize op started a newly created resize op while
it was also being concurrently started by another thread.
Fixes: #12664
Backport: hammer
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
Not bothering with this for non-namespaced object iterator
or the C interface. Expect to replace this with
the new-style pgls, so just exposing it enough for
cephfs-data-scan to touch the new osd-side pgls filtering
on forward scrub tags.
Signed-off-by: John Spray <john.spray@redhat.com>
The listen_sd of thread also can be zero when we call the processor::start function..
Reviewed-by: Kefu Chai <kchai@redhat.com>
Reviewed-by: Haomai Wang <haomaiwang@gmail.com>
These methods were not acquiring the ThreadPool lock when
manipulating the work_queue collection. This was causing
occasional crashes within librbd when opening and closing
images.
Fixes: #12662
Backport: hammer, firefly
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
Otherwise, when the MonmapMonitor's PaxosService::dispatch() handles the
message, it will assert (as it should) because the op is marked as being
a monitor op. And this function should never handle monitor ops.
Signed-off-by: Joao Eduardo Luis <joao@suse.de>
Combined with the improvements to the diff_iterate API, this should
noticeably increase the speed of a large image export-diff.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
If the diff_iterate callback returns an error, it should
result in diff_iterate being aborted with the error code
propagated.
Fixes: #11593
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
Issue up to 'concurrent_management_ops' list_snap ops to the
OSDs concurrently. The iterate callbacks will continue to be
serialized -- clients that wish higher throughput should avoid
blocking to maximum performance.
Fixes: #11625
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
