After some exchange with Loic and the recent list discussion, the API of the EC plugin might need some clarification/extension in the ::encode method: Currently ::encode returns a map of bufferlists where the key is the index of [ 0 .. (m+k) ] and the value is the encoded buffer belonging to that stripe index: map<int, bufferlist> *encoded If a pyramid code is used the index would be [ 0 .. (m+k+(l*l_k)) ] where l is the number of local parity subgroups and l_k are the number of parity stripes per subgroup. The pyramid code would just chunk the input into the requested number of subgroups and compute local parity for them according to the configuration. With this API the caller has actually no clue how to group stripes together for intelligent placement allowing to keep subgroups with local parities together to minimize traffic during remapping and reconstruction. Either there is an additional function returning the location sub-group [ 0 .. l ] for each created chunk or the ::encode function returns the chunks already grouped like: vector<int, map<int, bufferlist> *encoded Probably it would be good to have both. However it is not clear, if you can actually remap/recover an OSD without destroying the locality of pyramid encoding and if you can at all define CRUSH rules honoring the idea of chunk locality where shrinking/extension of pools keeps the locality. Last question is, if a remapping/recovery action is only possible with the traffic going through the primary OSD. If locality cannot be supported sufficiently now or in the future, should the API stay as it is? The ::decode function is fine, since the plugin knows about the locality of the available chunks and will select the cheapest decoding possible. Cheers Andreas.-- 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
