Re: Could you resend the link to the pull request?

Re: Could you resend the link to the pull request?

[Sage Weil]

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.)

sage

Re: Could you resend the link to the pull request?

[Gregory Farnum]

On Tue, Dec 5, 2017 at 8:39 AM, Sage Weil <sweil@redhat.com> 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.
-Greg

Re: Could you resend the link to the pull request?

[Sage Weil]

On Tue, 5 Dec 2017, Gregory Farnum wrote:
> On Tue, Dec 5, 2017 at 8:39 AM, Sage Weil <sweil@redhat.com> 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

Re: Could you resend the link to the pull request?

[myoungwon oh]

Hi sage

I have worked on a rados op like TIER_PROMOTE (but, not finished yet)
I will make it a PR according to your comment.

Myoungwon
SK Telecom


2017-12-06 3:19 GMT+09:00 Sage Weil <sweil@redhat.com>:
> On Tue, 5 Dec 2017, Gregory Farnum wrote:
>> On Tue, Dec 5, 2017 at 8:39 AM, Sage Weil <sweil@redhat.com> 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
>