On Mon, 18 Apr 2016, Adam C. Emerson wrote: > > I think that in those cases, we let them use a wacky object -> PG > > mapping, and then have a linear/flat PG -> device mapping so they > > can still get some uniformity. > > > > This isn't completely general, but I'd want to see an example of > > something it can't express. Maybe those entanglement erasure codes > > that Veronica was talking about at FAST? > > > > Or maybe the key step is to not assume the PG is a hash range, but > > instead consider it an arbitrary bucket in the pool. > > Would the idea basically be in that case that we go from OID => > WHATEVER => DEVICE LIST without putting too many constraints on what > 'WHATEVER' is? Yeah, probably with the additional/implicit restriction that the OSD -> WHATEVER mapping is fixed. That way when a policy or topology change happens, we do O(num WHATEVERs) remapping work. It's the O(num objects) part that is really problematic. (I would say fundamental, but you *could* imagine something where you know the old and new mapping, and try both, or incrementall walk through them.. but, man, it would be ugly. At that point you're probably better of just migrating objects from pool A to pool B.) sage -- 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
