From: lianghaoshen <lianghaoshen@ubuntukylin.com>
To: Sage Weil <sage@inktank.com>
Cc: Li Wang <liwang@ubuntukylin.com>, ceph-devel@vger.kernel.org
Subject: Re: contraining crush placement possibilities
Date: Fri, 07 Mar 2014 16:32:48 +0800 [thread overview]
Message-ID: <53198430.9030409@ubuntukylin.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1403062055200.24219@cobra.newdream.net>
于 2014年03月07日 13:03, Sage Weil 写道:
> On Fri, 7 Mar 2014, Li Wang wrote:
>> Sorry, it is (n/3)*(n/3)*(n/3)/Cn3 = n^3/(27*Cn3)
> Cn3 is "n choose 3"?
>
>>>>> Last night it occurred to me that this is almost just having
>>>>> pgp_num < pg_num, but I think that's not quite right either.
> Actually, maybe it is. Basically, say there are X combinations of 3 disks
> = n choose 3. Some fraction of these, say Y, are actually used by CRUSH.
> If we are to reduce that number, that implies that there are some PGs that
> are overlapping on the same set of disks. Which more or less reduces to
> the case where pgp_num < pg_num, or the hashpspool flag isn't set, or any
> other behavior that makes more than one PG line up on the same disk.
> Just using fewer PGs in the system, in fact, would help here. The main
Dose it mean that we can calculate the pgp_num according to the
reliability request, osd_num and replica_num, instead of using a given
fixed one, namely, 100 pgs/osd ? In fact , when the osd_num of a failure
domain is small , 100pgs can easily cover all of the osds, which means
data lost will occur, when the down osds are in different failure domains.
> problem is that doing this tends to make the distribution less uniform, so
> there is a tradeoff.
>
> There is a reliability model in ceph-tools.git at
>
> https://github.com/ceph/ceph-tools/tree/master/models/reliability
>
> that Mark Kampe built last year. Sadly I haven't looked at it closely so
> I'm not sure if it captures this.
>
> 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
--
Best regards,
slhhust
--
Best regards,
Lianghao Shen
--
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
next prev parent reply other threads:[~2014-03-07 8:39 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-06 20:30 contraining crush placement possibilities Sage Weil
2014-03-07 3:51 ` Li Wang
2014-03-07 3:53 ` Li Wang
2014-03-07 4:35 ` Li Wang
2014-03-07 5:03 ` Sage Weil
2014-03-07 8:32 ` lianghaoshen [this message]
2014-03-07 8:37 ` lianghaoshen
2014-03-07 8:45 ` Dan van der Ster
2014-03-07 10:30 ` Dan van der Ster
2014-03-07 15:10 ` Sage Weil
2014-03-07 17:29 ` Gregory Farnum
2014-03-07 17:43 ` Sage Weil
2014-03-07 18:00 ` Gregory Farnum
2014-03-10 9:37 ` Li Wang
2014-03-10 16:25 ` Gregory Farnum
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=53198430.9030409@ubuntukylin.com \
--to=lianghaoshen@ubuntukylin.com \
--cc=ceph-devel@vger.kernel.org \
--cc=liwang@ubuntukylin.com \
--cc=sage@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.