<div dir="ltr"><div>Thanks all for your quick responses and for the value you bring to the community.<br><br></div><div>I realized my terminology 'SNAFU' as soon as I hit send, so thanks for the clarification. <br>
<br></div><div>Lastly, can you provide an ETA as to when EC within Swift will become production ready?<br></div><div>If that is confidential I understand.<br><br>Thanks!<br></div><div><br></div><br></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Wed, Aug 13, 2014 at 4:57 PM, Luse, Paul E <span dir="ltr"><<a href="mailto:paul.e.luse@intel.com" target="_blank">paul.e.luse@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">






<div link="#0563C1" vlink="#954F72" lang="EN-US">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#44546a">The answer totally depends on how you choose to configure EC.  We generally refer to the “extra storage” as the overhead of the durability policy.  For triple
 replication, obviously its 3x (you buy 3x the usable capacity you need).  For EC it depends not only on which scheme you choose but the partakers that you configure.  For example Swift will support a few different Read Solomon schemes out of the box (when
 its done) and from there you can choose the ratio of data:parity such as 10:4 where you’d have 14 total disks, 10 of them for data and 4 for parity.  In this scheme you could lose 4 disks and still recover your data and your overhead would be 1.4 (14/10) as
 opposed to triple replication of 3 (3/1)<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#44546a"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#44546a">-Paul<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#44546a"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Brent Troge [mailto:<a href="mailto:brenttroge2016@gmail.com" target="_blank">brenttroge2016@gmail.com</a>]
<br>
<b>Sent:</b> Wednesday, August 13, 2014 2:41 PM<br>
<b>To:</b> <a href="mailto:openstack@lists.openstack.org" target="_blank">openstack@lists.openstack.org</a><br>
<b>Subject:</b> [Openstack] Swift And Erasure Code Storage<u></u><u></u></span></p><div class="">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal">With a 100% 'Erasure Code' policy how much extra storage is needed to satisfy a 1PB usable cluster ?<br>
<br>
 <u></u><u></u></p>
</div>
</div></div>
</div>

</blockquote></div><br></div>