Re: [ceph-users] cls_rbd ops on rbd_id.$name objects in EC pool

On Thu, 11 Feb 2016, Robert LeBlanc wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Is this only a problem with EC base tiers or would replicated base > tiers see this too? In general proxying to the base tier will work just fine if its replicated, so this is mostly an EC-only

Re: [ceph-users] cls_rbd ops on rbd_id.$name objects in EC pool

On Thu, 11 Feb 2016, Sage Weil wrote: > On Thu, 11 Feb 2016, Nick Fisk wrote: > > That’s a relief, I was sensing a major case of face palm occuring when I > > read Jason's email!!! > > https://github.com/ceph/ceph/pull/7617 > > The tangled logic in maybe_handle_cache wasn't respecting the force

Re: [ceph-users] cls_rbd ops on rbd_id.$name objects in EC pool

> -Original Message- > From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel- > ow...@vger.kernel.org] On Behalf Of Sage Weil > Sent: 12 February 2016 13:15 > To: Nick Fisk > Cc: 'Jason Dillaman' ; 'Samuel Just' > ;

Re: [ceph-users] cls_rbd ops on rbd_id.$name objects in EC pool

> -Original Message- > From: Nick Fisk [mailto:n...@fisk.me.uk] > Sent: 12 February 2016 13:31 > To: 'Sage Weil' > Cc: 'Jason Dillaman' ; 'Samuel Just' > ; ceph-users@lists.ceph.com; ceph- > de...@vger.kernel.org > Subject: RE:

Re: [ceph-users] cls_rbd ops on rbd_id.$name objects in EC pool

I think I see the problem. It looks like you are performing ops directly against the cache tier instead of the base tier (assuming cache1 is your cache pool). Here are my steps against master where the object is successfully promoted upon 'rbd info': # ceph osd erasure-code-profile set

Re: [ceph-users] cls_rbd ops on rbd_id.$name objects in EC pool

That class method flag to force promotion was to prevent proxying lock/unlock class ops. What was happening was that the cache tier OSD would become the owner of the lock instead of the client (retrieved via cls_get_request_origin). -- Jason Dillaman - Original Message - > From:

Re: [ceph-users] cls_rbd ops on rbd_id.$name objects in EC pool

I'm trying to reproduce this. Jason, I found your commit marks certain cls ops and requiring promotion, but that doesn't include rbd... and I'm not sure why info would need to be promoted. Working on reproducing this under hammer with the appropriate recency settings. sage On Thu, 11 Feb

Re: [ceph-users] cls_rbd ops on rbd_id.$name objects in EC pool

Hi Jason, It's in writeback mode. Nick > -Original Message- > From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel- > ow...@vger.kernel.org] On Behalf Of Jason Dillaman > Sent: 11 February 2016 18:40 > To: Nick Fisk > Cc: Sage Weil ; Samuel Just

Re: [ceph-users] cls_rbd ops on rbd_id.$name objects in EC pool

That’s a relief, I was sensing a major case of face palm occuring when I read Jason's email!!! > -Original Message- > From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel- > ow...@vger.kernel.org] On Behalf Of Sage Weil > Sent: 11 February 2016 21:00 > To: Jason Dillaman

Re: [ceph-users] cls_rbd ops on rbd_id.$name objects in EC pool

On Thu, 11 Feb 2016, Nick Fisk wrote: > That’s a relief, I was sensing a major case of face palm occuring when I > read Jason's email!!! https://github.com/ceph/ceph/pull/7617 The tangled logic in maybe_handle_cache wasn't respecting the force promotion bool.

Re: [ceph-users] cls_rbd ops on rbd_id.$name objects in EC pool

I was able to reproduce this on master: On Thu, 11 Feb 2016, Jason Dillaman wrote: > I think I see the problem. It looks like you are performing ops directly > against the cache tier instead of the base tier (assuming cache1 is your > cache pool). Here are my steps against master where the

Re: [ceph-users] cls_rbd ops on rbd_id.$name objects in EC pool

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Is this only a problem with EC base tiers or would replicated base tiers see this too? - Robert LeBlanc PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1 On Thu, Feb 11, 2016 at 6:09 PM, Sage Weil wrote: > On

Re: [ceph-users] cls_rbd ops on rbd_id.$name objects in EC pool

Hi Sage, Do you think this will get fixed in time for the Jewel release? It still seems to happen in Master and is definitely related to the recency setting. I'm guessing that the info command does some sort of read and then a write. In the old behaviour the read would have always triggered a

Re: [ceph-users] cls_rbd ops on rbd_id.$name objects in EC pool

What's your cache mode? In the master branch, I would expect that class method ops should force a promotion to the cache tier if the base tier is an EC pool [1]. [1] https://github.com/ceph/ceph/blob/master/src/osd/OSD.cc#L8905 -- Jason Dillaman - Original Message - > From: "Nick

[ceph-users] cls_rbd ops on rbd_id.$name objects in EC pool

On Wed, 27 Jan 2016, Nick Fisk wrote: > > > -Original Message- > > From: ceph-users [mailto:ceph-users-boun...@lists.ceph.com] On Behalf Of > > Jason Dillaman > > Sent: 27 January 2016 14:25 > > To: Nick Fisk > > Cc: ceph-users@lists.ceph.com > > Subject: Re:

Re: [ceph-users] cls_rbd ops on rbd_id.$name objects in EC pool

On Fri, 5 Feb 2016, Samuel Just wrote: > On Fri, Feb 5, 2016 at 7:53 AM, Jason Dillaman wrote: > > #1 and #2 are awkward for existing pools since we would need a tool to > > inject dummy omap values within existing images. Can the cache tier > > force-promote it from the

Re: [ceph-users] cls_rbd ops on rbd_id.$name objects in EC pool

It seems like the cache tier should force promote when it gets an op the backing pool doesn't support. I think using the cache-pin mechanism would make sense. -Sam On Fri, Feb 5, 2016 at 7:53 AM, Jason Dillaman wrote: > #1 and #2 are awkward for existing pools since we

Re: [ceph-users] cls_rbd ops on rbd_id.$name objects in EC pool

#1 and #2 are awkward for existing pools since we would need a tool to inject dummy omap values within existing images. Can the cache tier force-promote it from the EC pool to the cache when an unsupported op is encountered? There is logic like that in jewel/master for handling the proxied

Re: [ceph-users] cls_rbd ops on rbd_id.$name objects in EC pool

> -Original Message- > From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel- > ow...@vger.kernel.org] On Behalf Of Sage Weil > Sent: 05 February 2016 18:45 > To: Samuel Just > Cc: Jason Dillaman ; Nick Fisk ; >