> 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.... > > 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. > > ? > > 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 > > 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
