Re: K/V interface buffer transaction

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.Roy@xxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux