On Tue, 5 Dec 2017, Gregory Farnum wrote: > On Tue, Dec 5, 2017 at 8:39 AM, Sage Weil <sweil@xxxxxxxxxx> wrote: > > On Tue, 5 Dec 2017, Ken Iizawa wrote: > >> I'm sorry, but I failed to save the link to the pull request you told > >> me about in today's meeting. > >> Could you resend the link? > > > > https://github.com/ceph/ceph/pull/15482 > > > > There is a bunch of stuff in there, sorry. What we really want is a rados > > op that triggers promote_object(). We don't have that quite yet. > > > > Myoungwon, is that something you've looked at yet? I'm thinking of a > > rados op like TIER_PROMOTE (or something along those lines) that just > > triggers a promotion if it is a redirect/chunked manifest, and is a no-op > > otherwise. (We could probably make it do something meaningful for a cache > > tier too, but I don't think it's worth the effort.) > > Didn't we previously have something like that? All I see in the source > now is a CACHE_EVICT|FLUSH|TRY_FLUSH (or some new? CACHE_PIN|UNPIN), > but ops to control promotion/demotion were definitely on the drawing > board at one point, and I thought it was implemented. > > Grepping through logs I do see we had a CEPH_OSD_RMW_FLAG_PROMOTE in > 2015, though that's later than I was thinking. Not sure if I'm just > missing the right term to search for or if I'm making it up. We never did. The FLUSH/EVICT are the opposite (but roughly analogous) operations for a cache tier sitting above (vs an archive tier sitting below) the base tier, which are probably what you're thinking of? The struggle has historically been to *avoid* promotion, not to trigger promotion. sage -- 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
