question about backfill on erasure pool

question about backfill on erasure pool

[huang jun]

hi,all
i have a question about pg backfill on erasure pool.
pg0 in erasure pool, which k:m=2:1,
at first, pg0 on osd [1,2,3], after osd.4 added,
the pg0 is now distribute to osd [1,2,4],
for replicated pool, it will do backfill from primary(osd.1) to osd.4,
for erasure code pool, the primary osd.1 needs to read the data chunks
from osd.1 and osd.2,
then decode and push the parity chunk to osd.4,
in the above case, the osd.3 is up and contain the parity chunk,
why dont let osd.3 push the parity chunk to osd.4?

Re: question about backfill on erasure pool

[Sage Weil]

On Tue, 13 Dec 2016, huang jun wrote:
> hi,all
> i have a question about pg backfill on erasure pool.
> pg0 in erasure pool, which k:m=2:1,
> at first, pg0 on osd [1,2,3], after osd.4 added,
> the pg0 is now distribute to osd [1,2,4],
> for replicated pool, it will do backfill from primary(osd.1) to osd.4,
> for erasure code pool, the primary osd.1 needs to read the data chunks
> from osd.1 and osd.2,
> then decode and push the parity chunk to osd.4,
> in the above case, the osd.3 is up and contain the parity chunk,
> why dont let osd.3 push the parity chunk to osd.4?

I don't think there is any reason why we couldn't... it just hasn't been 
implemented.  Sam?

sage

Re: question about backfill on erasure pool

[Samuel Just]

Actually, I'm not sure it wouldn't read the parity chunk from osd.3,
I'd have to check.  However, the data would still go through the
primary.
-Sam

On Tue, Dec 13, 2016 at 4:48 AM, Sage Weil <sage@newdream.net> wrote:
> On Tue, 13 Dec 2016, huang jun wrote:
>> hi,all
>> i have a question about pg backfill on erasure pool.
>> pg0 in erasure pool, which k:m=2:1,
>> at first, pg0 on osd [1,2,3], after osd.4 added,
>> the pg0 is now distribute to osd [1,2,4],
>> for replicated pool, it will do backfill from primary(osd.1) to osd.4,
>> for erasure code pool, the primary osd.1 needs to read the data chunks
>> from osd.1 and osd.2,
>> then decode and push the parity chunk to osd.4,
>> in the above case, the osd.3 is up and contain the parity chunk,
>> why dont let osd.3 push the parity chunk to osd.4?
>
> I don't think there is any reason why we couldn't... it just hasn't been
> implemented.  Sam?
>
> 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

Re: question about backfill on erasure pool

[huang jun]

2016-12-13 23:42 GMT+08:00 Samuel Just <sjust@redhat.com>:
> Actually, I'm not sure it wouldn't read the parity chunk from osd.3,
> I'd have to check.  However, the data would still go through the
> primary.
you reminder me, i will check the osd log,
it is expected if the osd1 read the parity chunk from osd.3(shard 2)
and then push it to osd.4?
> -Sam
>
> On Tue, Dec 13, 2016 at 4:48 AM, Sage Weil <sage@newdream.net> wrote:
>> On Tue, 13 Dec 2016, huang jun wrote:
>>> hi,all
>>> i have a question about pg backfill on erasure pool.
>>> pg0 in erasure pool, which k:m=2:1,
>>> at first, pg0 on osd [1,2,3], after osd.4 added,
>>> the pg0 is now distribute to osd [1,2,4],
>>> for replicated pool, it will do backfill from primary(osd.1) to osd.4,
>>> for erasure code pool, the primary osd.1 needs to read the data chunks
>>> from osd.1 and osd.2,
>>> then decode and push the parity chunk to osd.4,
>>> in the above case, the osd.3 is up and contain the parity chunk,
>>> why dont let osd.3 push the parity chunk to osd.4?
>>
>> I don't think there is any reason why we couldn't... it just hasn't been
>> implemented.  Sam?
>>
>> 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



-- 
Thank you!
HuangJun

Re: question about backfill on erasure pool

[huang jun]

after check the osd log and ECBackend.cc source code,
when doing backfill, the osd.1 will read the parity chunk from osd.3,
and then push it to osd.4,
don't need to read data chunks from osd.1 and osd.2, and decode, then
send osd.4 parity chunk,
my former understanding is wrong.

thanks.

2016-12-14 9:01 GMT+08:00 huang jun <hjwsm1989@gmail.com>:
> 2016-12-13 23:42 GMT+08:00 Samuel Just <sjust@redhat.com>:
>> Actually, I'm not sure it wouldn't read the parity chunk from osd.3,
>> I'd have to check.  However, the data would still go through the
>> primary.
> you reminder me, i will check the osd log,
> it is expected if the osd1 read the parity chunk from osd.3(shard 2)
> and then push it to osd.4?
>> -Sam
>>
>> On Tue, Dec 13, 2016 at 4:48 AM, Sage Weil <sage@newdream.net> wrote:
>>> On Tue, 13 Dec 2016, huang jun wrote:
>>>> hi,all
>>>> i have a question about pg backfill on erasure pool.
>>>> pg0 in erasure pool, which k:m=2:1,
>>>> at first, pg0 on osd [1,2,3], after osd.4 added,
>>>> the pg0 is now distribute to osd [1,2,4],
>>>> for replicated pool, it will do backfill from primary(osd.1) to osd.4,
>>>> for erasure code pool, the primary osd.1 needs to read the data chunks
>>>> from osd.1 and osd.2,
>>>> then decode and push the parity chunk to osd.4,
>>>> in the above case, the osd.3 is up and contain the parity chunk,
>>>> why dont let osd.3 push the parity chunk to osd.4?
>>>
>>> I don't think there is any reason why we couldn't... it just hasn't been
>>> implemented.  Sam?
>>>
>>> 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
>
>
>
> --
> Thank you!
> HuangJun