In general, you do need to preserve the order. You are free to determine when re-ordering is safe though. -Sam
On Tue, Feb 10, 2015 at 8:59 AM, Somnath Roy <somnath....@sandisk.com> wrote: > Hi Sage/Haomai, > Our K/V store works best if the keys of the objects within a transaction are > sorted. We are writing a new K/V Db interface and planning to sort the keys > within a transaction. So, this raises one question, do we need to preserve > the order of the operation within a transaction ? > With the latest Ceph code, we are getting the following operations within a > transaction. > > 2015-02-09 19:00:21.885646 7fde2a573700 0 Before ZSMPut :: p_num_obj = 9 > 2015-02-09 19:00:21.885653 7fde2a573700 0 p_obj[p_num_obj].flags = 0 > 2015-02-09 19:00:21.885656 7fde2a573700 0 p_obj[p_num_obj].key_len = 83 > 2015-02-09 19:00:21.885657 7fde2a573700 0 p_obj[p_num_obj].data_len = 225 > 2015-02-09 19:00:21.885660 7fde2a573700 0 p_obj[p_num_obj].key = > _GHOBJTOSEQ_^A1%e6e_head!E63730A9!!1!!rbd_data%e100574b0dc51%e0000000000000689!headÿ > 2015-02-09 19:00:21.885663 7fde2a573700 0 p_obj[p_num_obj].flags = 0 > 2015-02-09 19:00:21.885664 7fde2a573700 0 p_obj[p_num_obj].key_len = 64 > 2015-02-09 19:00:21.885665 7fde2a573700 0 p_obj[p_num_obj].data_len = 178 > 2015-02-09 19:00:21.885666 7fde2a573700 0 p_obj[p_num_obj].key = > _SEQ_0000000000000361__OBJOMAP__^A0000000011.00000000000000000554 > 2015-02-09 19:00:21.885668 7fde2a573700 0 p_obj[p_num_obj].flags = 0 > 2015-02-09 19:00:21.885669 7fde2a573700 0 p_obj[p_num_obj].key_len = 39 > 2015-02-09 19:00:21.885671 7fde2a573700 0 p_obj[p_num_obj].data_len = 4 > 2015-02-09 19:00:21.885672 7fde2a573700 0 p_obj[p_num_obj].key = > _SEQ_0000000000000361__OBJOMAP__^A_epoch > 2015-02-09 19:00:21.885673 7fde2a573700 0 p_obj[p_num_obj].flags = 0 > 2015-02-09 19:00:21.885674 7fde2a573700 0 p_obj[p_num_obj].key_len = 38 > 2015-02-09 19:00:21.885675 7fde2a573700 0 p_obj[p_num_obj].data_len = 713 > 2015-02-09 19:00:21.885676 7fde2a573700 0 p_obj[p_num_obj].key = > _SEQ_0000000000000361__OBJOMAP__^A_info > 2015-02-09 19:00:21.885677 7fde2a573700 0 p_obj[p_num_obj].flags = 0 > 2015-02-09 19:00:21.885679 7fde2a573700 0 p_obj[p_num_obj].key_len = 48 > 2015-02-09 19:00:21.885680 7fde2a573700 0 p_obj[p_num_obj].data_len = 12 > 2015-02-09 19:00:21.885681 7fde2a573700 0 p_obj[p_num_obj].key = > _SEQ_0000000000000361__OBJOMAP__^Acan_rollback_to > 2015-02-09 19:00:21.885682 7fde2a573700 0 p_obj[p_num_obj].flags = 0 > 2015-02-09 19:00:21.885683 7fde2a573700 0 p_obj[p_num_obj].key_len = 57 > 2015-02-09 19:00:21.885684 7fde2a573700 0 p_obj[p_num_obj].data_len = 12 > 2015-02-09 19:00:21.885685 7fde2a573700 0 p_obj[p_num_obj].key = > _SEQ_0000000000000361__OBJOMAP__^Arollback_info_trimmed_to > 2015-02-09 19:00:21.885686 7fde2a573700 0 p_obj[p_num_obj].flags = 0 > 2015-02-09 19:00:21.885688 7fde2a573700 0 p_obj[p_num_obj].key_len = 31 > 2015-02-09 19:00:21.885689 7fde2a573700 0 p_obj[p_num_obj].data_len = 65536 > 2015-02-09 19:00:21.885690 7fde2a573700 0 p_obj[p_num_obj].key = > _SEQ_0000000000001345_STRIP_^A54 > 2015-02-09 19:00:21.885691 7fde2a573700 0 p_obj[p_num_obj].flags = 0 > 2015-02-09 19:00:21.885692 7fde2a573700 0 p_obj[p_num_obj].key_len = 34 > 2015-02-09 19:00:21.885693 7fde2a573700 0 p_obj[p_num_obj].data_len = 273 > 2015-02-09 19:00:21.885695 7fde2a573700 0 p_obj[p_num_obj].key = > _SEQ_0000000000001345__OBJATTR__^A_ > 2015-02-09 19:00:21.885696 7fde2a573700 0 p_obj[p_num_obj].flags = 0 > 2015-02-09 19:00:21.885697 7fde2a573700 0 p_obj[p_num_obj].key_len = 40 > 2015-02-09 19:00:21.885698 7fde2a573700 0 p_obj[p_num_obj].data_len = 31 > 2015-02-09 19:00:21.885699 7fde2a573700 0 p_obj[p_num_obj].key = > _SEQ_0000000000001345__OBJATTR__^Asnapset > > Looking at this it seems we don't need to preserve the order. > But, if I can remember correctly, at some point there will be some pglog trim > operation will be issued from upstream and that may require some ordering. > Please share your thought around this. > > Thanks & Regards > Somnath > > ________________________________ > > PLEASE NOTE: The information contained in this electronic mail message is > intended only for the use of the designated recipient(s) named above. If the > reader of this message is not the intended recipient, you are hereby notified > that you have received this message in error and that any review, > dissemination, distribution, or copying of this message is strictly > prohibited. If you have received this communication in error, please notify > the sender by telephone or e-mail (as shown above) immediately and destroy > any and all copies of this message in your possession (whether hard copies or > electronically stored copies). > > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
