Keep it all in one place (try_mark_clean()). The key behavioral change
is that we update last_epoch_clean and last_epoch_started when we are
peered too, only only when we are active.
Signed-off-by: Sage Weil <sage@redhat.com>
If we are fabricating the pg history values, we need something that is
reasonably valid, but that won't screw up peering of the PG by indicating
that the PG has peered at some point later than when it really has.
Otherwise we can end up in a situation where everyone thinks there is a
newer pg info out there that doesn't actually exist, and the PG will end
up as incomplete.
Signed-off-by: Sage Weil <sage@redhat.com>
Change the content of this field to be the last_epoch_clean for the PG
when it tells the mon it is ready to be merged.
This will later be used to populate the last_epoch_clean and
last_epoch_started fields in PG::merge_from() in certain corner cases.
Signed-off-by: Sage Weil <sage@redhat.com>
mgr/dashboard: Catch LookupError when checking the RGW status
Reviewed-by: Patrick Nawracay <pnawracay@suse.com>
Reviewed-by: Sebastian Wagner <sebastian.wagner@suse.com>
In https://github.com/ceph/ceph/pull/21580 I set a trap to catch some wired
and random segmentfaults and in a recent QA run I was able to observe it was
successfully triggered by one of the test case, see:
```
http://qa-proxy.ceph.com/teuthology/xxg-2018-07-30_05:25:06-rados-wip-hb-peers-distro-basic-smithi/2837916/teuthology.log
```
The root cause is that there might be holes on log versions, thus the
approx_size() method should (almost) always overestimate the actual number of log entries.
As a result, we might be at the risk of overtrimming log entries.
https://github.com/ceph/ceph/pull/18338 reveals a probably easier way
to fix the above problem but unfortunately it also can cause big performance regression
and hence comes this pr..
Signed-off-by: xie xingguo <xie.xingguo@zte.com.cn>
Now bluestore oncommit callback exec by osd op threads.
If there are multi threads of shard, it will cause out-of order.
For example, threads_per_shard=2
Thread1 Thread2
swap_oncommits(op1_oncommit)
swap_oncommits(op2_oncommit)
OpQueueItem.run(Op3)
op2_oncommit.complete();
op1_oncommit.complete()
This make oncommits out of order.
To avoiding this, we choose a fixed thread which has the smallest
thread_index of shard to do oncommit callback function.
Signed-off-by: Jianpeng Ma <jianpeng.ma@intel.com>
osd/PG: async-recovery should respect historical missing objects
Reviewed-by: Yan Jun <yan.jun8@zte.com.cn>
Reviewed-by: Josh Durgin <jdurgin@redhat.com>
We used first next_safe_pos in pending_safe to update journal's safe_pos, but
it might not be flushed at this time, so journal's header may get incorrect
write_pos in some case, which could cause mds damaged.
This fix is trying to use current min next_safe_pos in pending_safe to update
journal's safe_pos.
Signed-off-by: Zhi Zhang <zhangz.david@outlook.com>
Add a state for trash image.
Fixes: http://tracker.ceph.com/issues/25346
Signed-off-by: songweibin <song.weibin@zte.com.cn>
(cherry picked from commit 94140df624f33406c709dea270f07ed6ad6edac4)
When the exclusive lock is unlocked, the error code should be
-EBLACKLISTED when the client is blacklisted, otherwise -EROFS.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
If the watch has been lost, assume the lock has been lost but attempt
to reacquire it if and when the watch is re-established.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
This will ensure that it's possible to potentially re-acquire the
lock should the blacklist expire before the image is closed.
Fixes: http://tracker.ceph.com/issues/34534
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
Since it will periodically attempt to re-acquire the watch,
it will know when the RADOS client has been blacklisted and
when the blacklist has been removed.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
For example, if an image is blacklisted and the blacklist eventually
expires, the image should recover its watch.
Fixes: http://tracker.ceph.com/issues/34534
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
This will avoid a possible race between pre-queued status updates
firing between the time the state has been changed and the formatter
has been instantiated.
Fixes: http://tracker.ceph.com/issues/36084
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
