On Wed, Feb 11, 2015 at 8:36 AM, Somnath Roy <somnath....@sandisk.com> 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:sw...@redhat.com] > Sent: Tuesday, February 10, 2015 10:44 AM > To: Gregory Farnum > Cc: Somnath Roy; sj...@redhat.com; Haomai Wang (haomaiw...@gmail.com); 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 <sw...@redhat.com> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
