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
