[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ceph-devel
Subject:    State of the erasure code pyramid plugin
From:       Loic Dachary <loic () dachary ! org>
Date:       2014-01-30 8:04:15
Message-ID: 52EA077F.4070402 () dachary ! org
[Download RAW message or body]

Hi,

Your last comment made me realize I took an approach that is more complex than needed \
(the decode_chunks / encode_chunks methods are not necessary), which results in \
something that is also sub-optimal (it decodes too much and has no way to limit \
decoding to what is strictly necessary although this is precisely the point of the \
pyramid plugin). I see how to resolve it (rewrite recursion in terms of the \
encode()/decode() API instead of the encode_chunks()/decode_chunks() API and I'm half \
way thru). But since the feature freeze is Friday and given than it's not the only \
topic I care about, it is probably better to postpone. 

I'm quite happy that we now have a sound implementation plan. Even more that the \
current API is good enough. What remains to be done is:

* Rewrite of https://github.com/ceph/ceph/pull/1142 with encode()/decode()
* Complete the XOR plugin https://github.com/apeters1971/ceph/tree/wip-xor
* Implement a way ( moving the primary in the same datacenter as a failing OSD ? ) \
for pools to take advantage of the provided locality

I reorganized the tasks under http://tracker.ceph.com/issues/7266 to keep track of \
this. 

Cheers

-- 
Loïc Dachary, Artisan Logiciel Libre


["signature.asc" (application/pgp-signature)]
--
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

[prev in list] [next in list] [prev in thread] [next in thread]