Ceph

• It is better to do the changes within the same file to better read the diffs
• The changes are in the right direction but they will need to be smaller

I've reconsidered a bit, and I think it would be easier to leave most of the PG implementation where it is and factor out all of the ReplicatedPG logic (handling client IO, recovery) as implementing a PGBackend interface used by PG. This will be similar to the initial approach of cleaning up the PG/ReplicatedPG divison and implementing an ErasureCodedPG, except that we will be able to test the replicated and erasure coded implementations of the PGBackend through the PGBackend interface. This will allow us to more easily maintain a single implementation for most of the scrub, peering, and backfill logic (which should be fundamentally similar for both PG implementations).

[15:46:25] <sjustlaptop> the more I think about it, the more it became clear that factoring out the PG RecoveryState logic was going to be a nightmare
[15:46:32] <sjustlaptop> instead, we should essentially factor out everything else
[15:47:01] <sjustlaptop> nearly all of what we've done so far still applies
[15:48:44] <loicd> sjustlaptop: that makes sense to me. So PG.{cc,h} as it is would essentially become the RecoveryState & supporting functions. And what does not belong gets factored out. Is this what you mean ? 
[15:49:41] -*- loicd slightly paraphrasing http://tracker.ceph.com/issues/5433#note-6 :-)
[15:50:09] <sjustlaptop> loicd: yeah, that's the gist of it
[15:50:18] <sjustlaptop> also, backfill, scrub stay where they are
[15:50:31] <sjustlaptop> some replication logic (e.g., what to replicate and when) will move from ReplicatedPG to PG
[15:50:41] <sjustlaptop> how to replicate will remain in ReplicatedPG
[15:51:59] <sjustlaptop> correction: backfill is in ReplicatedPG, some of that logic will float up to PG
[15:52:28] <loicd> sjustlaptop: so ReplicatedPG would no longer exist as a derived class of PG. It would become a PGBackend from which PGReplicatedBackend and PGErasureCodeBackend are derived. And PG would use the PGBackend interface ?
[15:52:40] <sjustlaptop> yeah
[15:52:47] <loicd> I like that :-)
[15:52:50] <sjustlaptop> and hopefully, the PGBackends won't need a PG interface to work with at all
[15:53:38] <loicd> I'll go in this direction sjustlaptop , thanks :-)
[15:53:38] <sjustlaptop> that's my main beef with the current ReplicatedPG/PG setup, ReplicatedPG knows way too much about the contents of PG

Done elsewhere