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@xxxxxxxx> wrote: >> Am 14.12.2011 17:43, schrieb Tommi Virtanen: >>> On Wed, Dec 14, 2011 at 00:36, Jens Rehpöhler <jens.rehpoehler@xxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
