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