Re: ceph -w output

["Jens Rehpöhler" <jens.rehpoehler@filoo.de>]

Hi Sam,

thanks for the answers.

We began with osd3 und osd4 for internal reasons. osd1 to 3 will be
addes in near future.

I will wait until the patch is in the stables branch.

Thanks again

Jens


Am 15.12.2011 18:35, schrieb Samuel Just:
> Sorry for the delay.  It looks like you hit a corner case in our crush
> implementation.  The short version is that this bug got fixed last
> week in commit 14f8f00e579083db542568a60cd23d50055c92a3.
>
> The long version is that you have osd.3 and osd.4, but not osd.0,
> osd.1, or osd.2.  The pgs stuck in creating are the ones mapped
> specifically to osds 0, 1, and 2.  A pg ending in p# (like pg1.0p0) is
> supposed to map to osd.0 if possible.  With the above patch, those pgs
> should remap to available osds.
>
> -Sam
>
> On Thu, Dec 15, 2011 at 1:45 AM, Jens Rehpöhler
> <jens.rehpoehler@filoo.de> wrote:
>> Am 14.12.2011 17:43, schrieb Tommi Virtanen:
>>> On Wed, Dec 14, 2011 at 00:36, Jens Rehpöhler <jens.rehpoehler@filoo.de> wrote:
>>>> Attached you will find the output you asked for. Is there any limitation
>>>> on the amount of pools ? We create
>>>> pools for every customer and store their VM images in that pools. So we
>>>> will create a lot of pools over time.
>>> Each pool gets its own set of PGs (Placement Groups). An OSD that
>>> manages too many PGs will use a lot of RAM. What is "too many" is
>>> debatable, and really up to benchmarks, but considering we recommend
>>> about 100 PGs/OSD as a starting point, you probably don't want to go
>>> two orders of magnitude above that.
>> Ok .... that will serve our needs. Remains only the "creating" question.
>>
>> Any answers to that ?
>>
>> Thanks a lot !
>>
>> Jens
>>
>

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