> -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: cls_rbd ops on rbd_id.$name objects in EC pool
>
> > -Ori
> -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'
> ; ceph-users@lists.ceph.com; ceph-
> de...@vger.kernel.org
> Subject: RE
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
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 iss
-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 Thu,
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.
sage__
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
> Cc: Nick
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 obj
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 teutho
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: "S
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 ; ceph-
> us...@lists.ceph.com; cep
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 20
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
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 p
> -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 ;
> ceph-users@lists.ceph.com; ceph-de...@vger.kernel.org
> Subject: Re: cls_r
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 EC pool to the cache wh
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 would need a tool to injec
#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 wri
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: [ceph-users] Possible Cache T
19 matches
Mail list logo
