On 15/04/2016, Gregory Farnum wrote:
[snip]
> Well, I guess I don't have in-the-field information about the relative
> prevalence of these scenarios. But we definitely can't include
> features in RADOS that work "as long as you don't have acting set
> changes". ;)
[snip]
> This is something I've suggested in the past, but I think it's at the
> stage where somebody needs to write code demonstrating it is something
> approaching performant. If it is, I don't think anybody opposes the
> idea; if it's not, then throughput/IOP regressions are not a tradeoff
> Sam/Sage are willing to make for this IIRC (and, though I am more
> optimistic than I remember them being about our odds of success, I
> suppose I'm not either).
All right, I realize the issue now. Since the target can change if the primary
changes, the reply cache has to be not only persistent but replicated along a
PG. This makes plumbing and expiring it more complicated. But, since the reply
can be determined before sending the transaction down into the store, it
should still be fundamentally doable in a way that shouldn't hurt performance. (A
larger volume of data would need to be sent, but it should be sendable in the
same write.)
Obviously, testable code with a lack of performance regressions proclaims
and speculation about performance waits for a half hour then rides public
transportation, so I think we'll have to give this some thought and come
up with a working prototype to demonstrate the point.
So, I'll see if we can whip up a new description and a WIP branch on this
topic before too long.
--
Senior Software Engineer Red Hat Storage, Ann Arbor, MI, US
IRC: Aemerson@{RedHat, OFTC, Freenode}
0x80F7544B90EDBFB9 E707 86BA 0C1B 62CC 152C 7C12 80F7 544B 90ED BFB9
--
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
