> On Fri, 20 May 2016, Allen Samuels wrote: > > > On Fri, 20 May 2016, Allen Samuels wrote: > > > > > > I think having bluestore_min_alloc_size, > > > > > > bluestore_min_alloc_size_hdd, and bluestore_min_alloc_size_ssd > > > > > > still makes it easier to change for users. It'll only go in > > > > > > one bit of code that updates the BlueStore min_alloc_size member. > > > > > > > > > > If we really want to go down this road, would it make sense to > > > > > create storage class templates rather than global configuration > > > parameters? > > > > > Presumably you might want different compression, read ahead, or > > > > > writeback caching depending on the device class as well. > > > > > > > > I believe that administratively, you want to do this on a per-pool > > > > basis rather than on a device class basis. > > > > > > For min_alloc_size, I'm not sure we would vary this per-pool.. it > > > seems like it's a property of the device, not the data set. > > > > Agreed, I didn't proof-read what I sent. I was focused on the more > > data- and access-oriented things like compression, read-ahead, etc. > > Yes, block sizes are per-device not per-pool.... > > Excellent > > > > However, for compression and checksums, *definitely*. We just > > > brainstormed a bunch of bluestore config options to do this for > > > compression, but you're right that pretty much all of this should really be > a per-pool thing. > > > > > > I think that means we want to construct a bit of the ObjectStore > > > interface that passes the profile down to each Collection, and store > > > it there. Then the profile options would be interpreted there by > > > BlueStore. These would probably be > > > > > > compression mode = force | aggressive | passive | none compression > > > algorithm = snappy | zlib compression min blob size = 262144 > > > compression max blob size = 4194304 > > > > Let's make the per-pool thing more expressive and extensible than just > > for blue-store (maybe a JSON blob?). I believe that are LOTS more > > places where configuration information should be provided on a per-pool > basis. > > So we do already have an extensible pool property mechanism: > > https://github.com/ceph/ceph/blob/master/src/osd/osd_types.h#L > 959 > > It's not JSON, but it's extensible key/value pairs with values of int, double, or > string, which I think is enough here. Yes, it seems sufficient for this. > > > > 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*) > > 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
