Re: K/V interface buffer transaction

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

 



On Wed, Feb 11, 2015 at 8:36 AM, Somnath Roy <Somnath.Roy@xxxxxxxxxxx> wrote:
> Thanks Greg/Sam/Sage !
> For now, we will be doing our testing by sorting the keys and will keep an eye on the duplicates.
> Another point, why do we need the K/V store thread pool for processing transactions anymore ?
> I got rid of that and calling _do_transaction() directly from the ::queue_trasaction , this is giving me ~3X performance improvement.

WOW, I originally prepare to improve this but not aware we could get
so much improvement for this.

Look forward to this improvement.

>
> Regards
> Somnath
>
> -----Original Message-----
> From: Sage Weil [mailto:sweil@xxxxxxxxxx]
> Sent: Tuesday, February 10, 2015 10:44 AM
> To: Gregory Farnum
> Cc: Somnath Roy; sjust@xxxxxxxxxx; Haomai Wang (haomaiwang@xxxxxxxxx); Ceph Development
> Subject: Re: K/V interface buffer transaction
>
> On Tue, 10 Feb 2015, Gregory Farnum wrote:
>> On Tue, Feb 10, 2015 at 10:26 AM, Sage Weil <sweil@xxxxxxxxxx> wrote:
>> > On Tue, 10 Feb 2015, Somnath Roy wrote:
>> >> Thanks Sam !
>> >> So, is it safe to do ordering if in a transaction *no* remove/truncate/create/add call ?
>> >> For example, do we need to preserve ordering in case of the below transaction ?
>> >> It will be helpful if you can give some insight in what scenario preserving order is *must*.
>> >
>> > If I'm not mistaken teh only time ordering would matter at all in an
>> > transaction is when the same key is updated twice, right?  The whole
>> > thing is committed atomically.  If there *are* dups, then the order
>> > there obviously should be preserved.
>> >
>> > Maybe a first pass would be add an assert or something that there
>> > are no dup keys and see if anything every falls out of that...
>> > hopefully there are none!
>>
>> I'm pretty sure some of the transaction analysis discussions people
>> have had say that we do double-updates at times. IIRC it might have
>> been the pglog head getting set twice in most transactions?
>
> Oh yeah, could be.  There was the snapset xattr update, but that was resetting it to an existing value (not the same value inside the same txn).  I forget if there were others.
>
> sage
>
> ________________________________
>
> 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).
>



-- 
Best Regards,

Wheat
--
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