Sounds good. Sent from my iPhone. Please excuse all typos and autocorrects. > On May 21, 2016, at 11:11 AM, Sage Weil <sweil@xxxxxxxxxx> wrote: > > On Fri, 20 May 2016, Allen Samuels wrote: >>>>> The osd options are still useful for testing purposes, I think. >>>>> Maybe a simple policy that the per-pool options will just override >>>>> the config option if they are specified is sufficient? If we can >>>>> keep the pool and config options 1:1 (modulo the bluestore_ >>>>> prefix, perhaps) that would keep things understandable. >>>> >>>> +1 >>> >>> If we do this, we need to make a nice way to plumb hte pool properties >>> down to teh ObjectStore collections, but the nice thing is that if we >>> map 1:1 to config options we can focus on the bluestore functionality >>> now without that blocking us. >> >> Yes, hopefully when we do that we do it in a way that preserves the >> flexibility of the existing pool property mechanism, but avoids the cost >> of looking up in the pool_ops_t structure on each R/W traversal. In 5 >> minutes of looking at the pool_ops_t code, it wasn't apparent where the >> structure is loaded. In other words, if the current mechanism requires a >> re-start of the OSD after a parameter change then we might want to >> rethink it. Perhaps the properties can be augmented with a flag that >> indicates whether dynamic reloading of those particular parameters is >> supported (i.e., some properties take affect only on restart, others >> take effect *immediately*) > > We should be able to push everything down without too much trouble. > Something like > > OSD sees new osdmap > -> PG state update() > -> PGPool::update() > -> (new) ObjectStore::collection_set_params(...) > -> store local copy of values in BlueStore::Collection (in memory) > > with a similar path in load_pgs() on startup to get them initialized. > > Then the read/write path would either check in Collection field, then at > global value, or the global config update could iterate over collections > and update all of the collection-local fields. Probably the former, for > simplicity... > > 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
