PG state issue

PG state issue

[Henry C Chang]

Hi,

With version 0.42, I found that the pg's state is not in "degrade" any
more if the number of osds is smaller than that of the replication.
For example, if I create a cluster of one osd with replication 2, all
pgs are in active+clean state. (The pgs were in active+clean+degrade
state in the earlier versions.)

I think it should be a bug in terms of cluster status although it does
not cause any other problems to me so far.

Henry

Re: PG state issue

[Wido den Hollander]

Hi,

On 03/01/2012 10:43 AM, Henry C Chang wrote:
> Hi,
> With version 0.42, I found that the pg's state is not in "degrade" any
> more if the number of osds is smaller than that of the replication.
> For example, if I create a cluster of one osd with replication 2, all
> pgs are in active+clean state. (The pgs were in active+clean+degrade
> state in the earlier versions.)

Just a conformation from my side.

Currently I have 3 OSD's which our down/out and only one PG went into 
degraded state. The weird thing is, these OSD's are not acting for this PG.

The OSD's for this PG are all up and in.

Wido

>
> I think it should be a bug in terms of cluster status although it does
> not cause any other problems to me so far.
>
> Henry
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: PG state issue

[Sage Weil]

Hi Henry, Wido,

On Thu, 1 Mar 2012, Henry C Chang wrote:
> With version 0.42, I found that the pg's state is not in "degrade" any
> more if the number of osds is smaller than that of the replication.
> For example, if I create a cluster of one osd with replication 2, all
> pgs are in active+clean state. (The pgs were in active+clean+degrade
> state in the earlier versions.)

The PG states were tweaked a fair bit for v0.43:

- new 'recovering' state means we are actively recovering the PG (no 
  longer implied by lack of 'clean')
- 'remapped' means we have temporarily remapped a pg to a specific set of 
  OSDs (other than what CRUSH gives us)
- 'clean' specifically means we have the right number of replicas and 
  aren't remapped.

...and the 'degraded' thing you are seeing is fixed.  This is all in place 
in the 'next' or 'master' branches.

> I think it should be a bug in terms of cluster status although it does
> not cause any other problems to me so far.

Yeah, it's simply a matter of how the internal state is displayed/reported 
to the moitor.

sage

Re: PG state issue

[Henry C Chang]

Hi Sage,

I just tested v0.43. All pgs are shown active+degraded now. However,
is it possible to show the number (or percentage) of degraded objects
as in the earlier version?

Henry

在 2012年3月2日上午12:14，Sage Weil <sage@newdream.net> 寫道：
> Hi Henry, Wido,
>
> On Thu, 1 Mar 2012, Henry C Chang wrote:
>> With version 0.42, I found that the pg's state is not in "degrade" any
>> more if the number of osds is smaller than that of the replication.
>> For example, if I create a cluster of one osd with replication 2, all
>> pgs are in active+clean state. (The pgs were in active+clean+degrade
>> state in the earlier versions.)
>
> The PG states were tweaked a fair bit for v0.43:
>
> - new 'recovering' state means we are actively recovering the PG (no
>  longer implied by lack of 'clean')
> - 'remapped' means we have temporarily remapped a pg to a specific set of
>  OSDs (other than what CRUSH gives us)
> - 'clean' specifically means we have the right number of replicas and
>  aren't remapped.
>
> ...and the 'degraded' thing you are seeing is fixed.  This is all in place
> in the 'next' or 'master' branches.
>
>> I think it should be a bug in terms of cluster status although it does
>> not cause any other problems to me so far.
>
> Yeah, it's simply a matter of how the internal state is displayed/reported
> to the moitor.
>
> sage
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: PG state issue

[Sage Weil]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1830 bytes --]

On Mon, 5 Mar 2012, Henry C Chang wrote:
> Hi Sage,
> 
> I just tested v0.43. All pgs are shown active+degraded now. However,
> is it possible to show the number (or percentage) of degraded objects
> as in the earlier version?

Yeah.  Just opened http://tracker.newdream.net/issues/2137, will look at 
it this week.

Thanks!
sage


> 
> Henry
> 
> ÿÿ 2012ÿÿ3ÿÿ2ÿÿÿÿÿÿ12:14ÿÿSage Weil <sage@newdream.net> ÿÿÿÿÿÿ
> > Hi Henry, Wido,
> >
> > On Thu, 1 Mar 2012, Henry C Chang wrote:
> >> With version 0.42, I found that the pg's state is not in "degrade" any
> >> more if the number of osds is smaller than that of the replication.
> >> For example, if I create a cluster of one osd with replication 2, all
> >> pgs are in active+clean state. (The pgs were in active+clean+degrade
> >> state in the earlier versions.)
> >
> > The PG states were tweaked a fair bit for v0.43:
> >
> > - new 'recovering' state means we are actively recovering the PG (no
> >  longer implied by lack of 'clean')
> > - 'remapped' means we have temporarily remapped a pg to a specific set of
> >  OSDs (other than what CRUSH gives us)
> > - 'clean' specifically means we have the right number of replicas and
> >  aren't remapped.
> >
> > ...and the 'degraded' thing you are seeing is fixed.  This is all in place
> > in the 'next' or 'master' branches.
> >
> >> I think it should be a bug in terms of cluster status although it does
> >> not cause any other problems to me so far.
> >
> > Yeah, it's simply a matter of how the internal state is displayed/reported
> > to the moitor.
> >
> > sage
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
>