On Dec 18, 2013, Gregory Farnum <g...@inktank.com> wrote: > On Tue, Dec 17, 2013 at 3:36 AM, Alexandre Oliva <ol...@gnu.org> wrote: >> Here's an updated version of the patch, that makes it much faster than >> the earlier version, particularly when the gap between the latest osdmap >> known by the osd and the earliest osdmap known by the cluster is large.
> Is this actually still necessary in the latest dumpling and emperor > branches? I can't tell for sure, I don't recall when I last rolled back to an old snapshot without this kind of patch. > I thought sufficiently-old OSDs would go through backfill with the new > PG members in order to get up-to-date without copying all the data. That much is true, for sure. The problem was getting to that point. If the latest osdmap known by the osd snapshot turns out to be older than the earliest map known by the monitors, the osd would give up because it couldn't make the ends meet: no incremental osdmaps were available in the cluster, and the osd refused to jump over gaps in the osdmap sequence. That's why I fudged the unavailable intermediate osdmaps as clones of the latest one known by the osd: then it would apply the incremental changes as nops until it got to an actual newer map, in which it would notice a number of changes, apply them all, and get on its happy way towards recovery over each of the newer osdmaps ;-) I can give a try without the patch if you tell me there's any chance the osd might now be able to jump over gaps in the osdmap sequence. That said, the posted patch, ugly as it is, is meant as a stopgap rather than as a proper solution; dealing with osdmap gaps rather than dying would be surely a more desirable implementation. -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
