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.
