From: Li Wang <liwang@ubuntukylin.com>
To: Sage Weil <sage@inktank.com>, ceph-devel@vger.kernel.org
Subject: Re: contraining crush placement possibilities
Date: Fri, 07 Mar 2014 12:35:05 +0800 [thread overview]
Message-ID: <53194C79.20304@ubuntukylin.com> (raw)
In-Reply-To: <531942CF.2010202@ubuntukylin.com>
Sorry, it is (n/3)*(n/3)*(n/3)/Cn3 = n^3/(27*Cn3)
On 2014/3/7 11:53, Li Wang wrote:
> Provided 3 osds are down simultaneously
>
> On 2014/3/7 11:51, Li Wang wrote:
>> Just had a quick look. It seems crush could meet the demand,
>> say, if we have 100 osds, replica_num is 3, then we partition the
>> 100 osds into 3 trees, 'take' iterates on the 3 trees, for each tree,
>> select 1 osd. Then the probability of losing data is at most n*n*n/Cn3,
>> can we make it better?
>>
>>
>> On 2014/3/7 4:30, Sage Weil wrote:
>>> During the CRUSH CDS session yesterday I talked a bit about the
>>> desire to
>>> constrain the number of possible disk combinations so that we reduce the
>>> probability of a concurrent failure from causing data loss. Sheldon
>>> just
>>> pointed out a talk from ATC that discusses the basic problem:
>>>
>>>
>>> https://www.usenix.org/conference/atc13/technical-sessions/presentation/cidon
>>>
>>>
>>>
>>> The situation with CRUSH is slightly better, I think, because the number
>>> of peers for a given OSD in a large cluster is bounded (pg_num /
>>> num_osds), but I think we may still be able improve things.
>>>
>>> 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.
>>>
>>> If anyone has some clear intuition here, would love to hear it. If
>>> there
>>> is anything we can do to improve things we definitely want to do it!
>>>
>>> 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
>>>
> --
> 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 4:35 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 [this message]
2014-03-07 5:03 ` Sage Weil
2014-03-07 8:32 ` lianghaoshen
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=53194C79.20304@ubuntukylin.com \
--to=liwang@ubuntukylin.com \
--cc=ceph-devel@vger.kernel.org \
--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.