On 2014-09-18 13:01:03 +0000, Andreas Joachim Peters wrote: > > >> For encoding there is normally a single buffer split 'virtually' > >> into > >> k pieces. To make all pieces starting at an aligned address one > >> needs > >> to align the chunk size to e.g. 16*k. > > >I don't get that. How is the buffer splitted? into k (+ m) chunk size > >parts? As long as the start and the length are both 16 (or 32) byte > >aligned all parts are properly aligned too. I don't see where the k > >comes into play. > > The original data block to encode has to be split into k equally long > pieces. Each piece is given as one of the k input buffers to the > erasure code algorithm producing m output buffers and each piece has > to have an aligned starting address and length. > > If you deal with 128 byte data input buffers for k=4 it splits like > > offset=00 len=32 as chunk1 > offset=32 len=32 as chunk2 > offset=64 len=32 as chunk3 > offset=96 len=32 as chunk4 > > If the desired IO size would be 196 bytes the 32 byte alignment > requirement blows this buffer up to 256 bytes: > > offset=00 len=64 as chunk1 > offset=64 len=64 as chunk2 > offset=128 len=64 as chunk3 > offset=196 len=64 as chunk4 I fail to see how the 32 * k is related to alignment. It's only used for to pad the total size so it becomes a mulitple of k * 32. That is ok since we want k 32-byte aligned chunks. The alignment for each chunk is just 32-bytes. Janne -- 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
