Is this v12.2.4 without *any* modifications to the source code? As I mentioned in my other reply, because we set allow_limit_break to true, we should not be returning a “future”. Therefore the code should not have to consider this case. If you are using an unmodified v12.2.4 then I would be happy to dig into this further. Thank you, Eric > On Oct 15, 2018, at 8:07 AM, 韦皓诚 <whc0000001@xxxxxxxxx> wrote: > > ceph version 3b7325 (b3b7325f13d50ae2ab52ba0dff35e5cf66dec487) luminous (stable) > 1: (()+0xa3c751) [0x7fbf37a4d751] > 2: (()+0xf6d0) [0x7fbf342976d0] > 3: (gsignal()+0x37) [0x7fbf332b8277] > 4: (abort()+0x148) [0x7fbf332b9968] > 5: (ceph::__ceph_assert_fail(char const*, char const*, int, char > const*)+0x284) [0x7fbf37a8c824] > 6: (ceph::mClockQueue<std::pair<spg_t, PGQueueable>, > ceph::mClockOpClassQueue::osd_op_type_t>::dequeue()+0x45f) > [0x7fbf3776856f] > 7: (ceph::mClockOpClassQueue::dequeue()+0xd) [0x7fbf3776862d] > 8: (OSD::ShardedOpWQ::_process(unsigned int, > ceph::heartbeat_handle_d*)+0x314) [0x7fbf37524bf4] > 9: (ShardedThreadPool::shardedthreadpool_worker(unsigned int)+0x839) > [0x7fbf37a921c9] > 10: (ShardedThreadPool::WorkThreadSharded::entry()+0x10) [0x7fbf37a94160] > 11: (()+0x7e25) [0x7fbf3428fe25] > 12: (clone()+0x6d) [0x7fbf33380bad] > > The reason for this problem is what I said in the previous email. And > kefu chai told me it will cause a assert and abort OSD. > Previous Email: > Hi guys > Class mClockQueue calls PullPriorityQueue::pull_request in function > dequeue() . But PullPriorityQueue::pull_request may return a "future" > value. That means the mclock tag of the request are greater than now, > so it should be executed in the future instead of now.The mistake is > that the mClockQueue::dequeue() do not consider about the type of return value > > This situation is very likely to occur in practice. If we set scrub > limit value > 0, this situation will occur when there is no client op > at the moment and scrub is triggerd.
