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@xxxxxxxxx>: > 2016-12-13 23:42 GMT+08:00 Samuel Just <sjust@xxxxxxxxxx>: >> 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@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx >>> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > -- > Thank you! > HuangJun -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
