From: Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
To: Mark Nelson <mark.nelson@inktank.com>
Cc: Dan Mick <dan.mick@inktank.com>, ceph-devel <ceph-devel@vger.kernel.org>
Subject: Re: [ceph-commit] HEALTH_WARN 192 pgs degraded
Date: Fri, 26 Oct 2012 11:53:11 +1300 [thread overview]
Message-ID: <5089C2D7.7090307@catalyst.net.nz> (raw)
In-Reply-To: <CAJCPpWJy=k2Sw6iRH-wPq85uWCY7yRA3yE6kBUYwfuQsm2Hz7g@mail.gmail.com>
On 25/10/12 17:55, Mark Nelson wrote:
> On Wed, Oct 24, 2012 at 10:58 PM, Dan Mick <dan.mick@inktank.com> wrote:
>
>> HEALTH_WARN 192 pgs degraded; 192 pgs stuck unclean; recovery 21/42
>>> The other alternative is to just set the pool(s) replication size to 1,
>>> if you are just wanting a single osd for (say) testing:
>>>
>>> $ ceph osd pool set <your pool(s)> size 1
>>>
>>> I find it I need to restart ceph after doing the above, it then sorts
>>> itself out to a nice healthy status!
>>>
>>
>>
> I was actually just talking to Greg and Sam about this earlier today. If
> you rely on ceph health as part of an automated process to determine
> whether or not tests should start running, having degraded PGs due to some
> of the pools expecting 2x replication (when there is 1 OSD) is annoying.
> It will go away if whatever default pools are created get manually set to
> 1x replication, but it's not something that is immediately obvious. I
> don't know that changing the defaults is necessarily the right answer.
> Instead perhaps we just haven't done a good enough job of explaining what
> pools get created, how they are used, and when/if they should be modified
> in some way . Maybe this belongs in a FAQ?
>
Ah yes - you are quite right, it is *not* required to restart ceph to
make it sort out those stuck pages after changing the size. I believe at
some point (maybe < 0.50) it was and I had gotten into the habit!
+1 for adding a FAQ about the defaults pools and replication levels etc.
Cheers
Mark
prev parent reply other threads:[~2012-10-25 22:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5087F3AE.8080601@gmail.com>
2012-10-24 14:55 ` [ceph-commit] HEALTH_WARN 192 pgs degraded Josh Durgin
2012-10-24 15:40 ` Sage Weil
2012-10-25 0:05 ` Mark Kirkwood
2012-10-25 3:58 ` Dan Mick
[not found] ` <CAJCPpWJy=k2Sw6iRH-wPq85uWCY7yRA3yE6kBUYwfuQsm2Hz7g@mail.gmail.com>
2012-10-25 22:53 ` Mark Kirkwood [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5089C2D7.7090307@catalyst.net.nz \
--to=mark.kirkwood@catalyst.net.nz \
--cc=ceph-devel@vger.kernel.org \
--cc=dan.mick@inktank.com \
--cc=mark.nelson@inktank.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.