Hi, Thank you, everyone, for the help. I absolutely was mixing up the two, which is why I was asking for guidance. The example made it clear. The question I was trying to answer was: what would the capacity of the cluster be, for actual data, based on the raw disk space + server/drive count + erasure coding profile. It sounds like the 'usable' calculation (66% in this case) is the accurate number, assuming I were to fill the cluster to 100%, which I realize is not ideal with Ceph. Respectfully, David Orman On Wed, Jul 29, 2020 at 2:27 AM Janne Johansson <icepic.dz@gmail.com> wrote:
Den ons 29 juli 2020 kl 03:17 skrev David Orman <ormandj@corenode.com>:
That's what the formula on the ceph link arrives at, a 2/3 or 66.66% overhead. But if a 4 byte object is split into 4x1 byte chunks data (4 bytes total) + 2x 1 byte chunks parity (2 bytes total), you arrive at 6 bytes, which is 50% more than 4 bytes. So 50% overhead, vs. 33.33% overhead as the other formula arrives at. I'm curious what I'm missing.
Are you sure you are not just mixing up overhead with usable %?
50% overhead means you write 4 bytes, get 2 bytes "extra" for a total of 6. In this case 4 out of 6 is 66.67% usable space, i.e. two thirds.
So if the formula says you will get 66% usable it means you get two-thirds usable out of your drives with EC4+2, and it can also be said that the data is 100%, and the overhead is 50% of that, but you need to know which of the figures you want to calculate.
Either "how large is the growth of the data I put in" OR "How much of the stored data is my original bytes and how much in percent is the checksums".
For 4+2, the growth is 50%, since you add two (50% of four) to 4 original bytes, and for a six-drive setting, two drives go to checksums so you only get 66% usable if you fill that cluster up. The space allocated to checksums (33%) is "50% of 66%" so the overhead is still 50% no matter how you calculate i
-- May the most significant bit of your life be positive.