Commits on Apr 21, 2018

1. osd/PGLog: assert out on performing overflowed log trimming …

   Performing overflowed log-trim can be a sign of big trouble, e.g.,
   the **complete_to** iterator will now point to an invalid position
   of the original pg-log list when the trimming is done, and hence
   randomly trigger **Segmentation fault**s as below:
   ```
   2018-03-07 17:38:46.109018 7f274a4ed700 -1 *** Caught signal (Segmentation fault) **
   1: (()+0xa51f31) [0x7f278290bf31]
   2: (()+0xf370) [0x7f277fb4f370]
   3: (PrimaryLogPG::recover_got(hobject_t, eversion_t)+0x266) [0x7f2782512786]
   4: (PrimaryLogPG::on_local_recover(hobject_t const&, ObjectRecoveryInfo const&, std::shared_ptr<ObjectContext>, bool, ObjectStore::Tran
   saction*)+0x2a4) [0x7f278251f3b4]
   5: (ReplicatedBackend::handle_push(pg_shard_t, PushOp const&, PushReplyOp*, ObjectStore::Transaction*)+0x2e2) [0x7f2782690f82]
   6: (ReplicatedBackend::_do_push(boost::intrusive_ptr<OpRequest>)+0x194) [0x7f2782691224]
   7: (ReplicatedBackend::_handle_message(boost::intrusive_ptr<OpRequest>)+0x2f1) [0x7f278269fd41]
   8: (PGBackend::handle_message(boost::intrusive_ptr<OpRequest>)+0x50) [0x7f27825c2470]
   ```
   
   The root cause of why PGs are starting to trim more log entries than
   we expect is still lost to me, but setting the trap here should generally
   do no harm and hopefully expose the above problem a little bit more offen.
   We'll see.
   
   Signed-off-by: xie xingguo <xie.xingguo@zte.com.cn>

   

   xiexingguo committed Apr 21, 2018
   Copy the full SHA

   8a395f2 View commit details

   Browse the repository at this point in the history