on commands that use 'start' and 'stop'/'end' values, we should validate
them and inform the user when 'stop' > 'start'.
Signed-off-by: Joao Eduardo Luis <joao@redhat.com>
Because "file_events" is "FileEvent" type and adding an integral value to
this pointer automatically scales that value by the size.
Signed-off-by: Haomai Wang <haomaiwang@gmail.com>
we can return immediately if no snapc need to trim. Do not iterater snapc vector and do extra judgement and ops.
Signed-off-by: Ning Yao <zay11022@gmail.com>
Currently we make each monitor apply the incremental and encode the full
map locally. The original motivation was to save bandwidth, but the
savings are minimal to modest and the complexity associated with doing this
is huge.
This strategy also causes problems now that we have OSDMap crc's and old
mons/clusters may have diverging full OSDMaps due to mixed version
clusters. See #10422
Instead, include the encoded full map in the paxos transaction. We will
still apply the incremental and check the crc, but if it fails and we have
the correct version, reload it from disk and move on. If we don't, we
will continue as we have before--the primary mon doesn't have support for
crc's yet. When it does we will start verifying and/or get our
full map back into sync.
Fixes: #10422
Signed-off-by: Sage Weil <sage@redhat.com>
Currently we can have a race like so:
- send op in epoch X
- osd replies
- pool deleted in epoch X+1
- client gets X+1, sends map epoch check
- client gets reply
-> fails assert that there is no map check in flight
Avoid this situation by inferring that the pool is deleted when we see
that we previously sent the request but the pool is no longer present.
Since pool ids are not reused there is no point in doing a synchronous
map check at all.
Backport: giant
Fixes: #10372
Signed-off-by: Sage Weil <sage@redhat.com>
According to documentation, ioprio params will only be used if both
osd disk thread ioprio class and osd disk thread ioprio priority are
set to a non default value.
So, add a proper check and do not generate "set_disk_tp_priority(22)
Invalid argument" warning for the default settings.
If connection holds Connection's lock and try to acquire
FakeDispatcher's lock while gtest thread try to send_message with
FakeDispatcher's lock and try to acquire Connection's lock,
it will be deadlock.
Signed-off-by: Haomai Wang <haomaiwang@gmail.com>
Make learn_addr become a async op, otherwise holding connection's
lock then acquire messenger's lock will destroy lock rule.
Signed-off-by: Haomai Wang <haomaiwang@gmail.com>
Now AsyncConnection::_stop may consume a little time on deleting time events,
it may occur that accepting a connection get this stopping connection
because unregister call isn't met.
Signed-off-by: Haomai Wang <haomaiwang@gmail.com>
Users can easily forget this. It makes shutdown potentially block, but if
they have racing callbacks they get what they ask for.
Signed-off-by: Sage Weil <sage@redhat.com>
(cherry picked from commit 30678f6daf)
Add a call so that callers can make sure all queued callbacks have
completed before shutting down the ioctx. This avoids a segv triggered
by the LibRadosWatchNotifyPPTests/LibRadosWatchNotifyPP.WatchNotify2Timeout/1
test due to the ioctx being destroyed when the in-progress callback
does a notify_ack.
Signed-off-by: Sage Weil <sage@redhat.com>
(cherry picked from commit 4ebd4b4280)
The notify completion has exactly one user, the librados caller which
does nothing but take a local (inner) lock and signal a Cond. Do this
in the fast-dispatch context for simplicity.
Notably, this makes the notify completion (and timeout) trigger a
notify2() return (with ETIMEDOUT) even when the finisher queue that
normally delivers notify is busy.. for example with a notify that is
being very slow. In our case, the unit test is doing a sleep(3) to
test timeouts but also prevented the ETIMEDOUT notification from
being delivered to the caller. This patch resolves that.
Signed-off-by: Sage Weil <sage@redhat.com>
(cherry picked from commit 9b78dafd4a)
