Hi, On Mon, Sep 21, 2015 at 04:32:19PM +0300, Mykola Golub wrote: > On Wed, Sep 16, 2015 at 09:23:07AM -0700, Sage Weil wrote: > > On Wed, 16 Sep 2015, GuangYang wrote: > > > Hi Sam, > > > As part of the effort to solve problems similar to issue #13104 (http://tracker.ceph.com/issues/13104), do you think it is appropriate to add some parameters to pool setting: > > > 1. recovery priority of the pool - we have a customized pool recovery priority (like process's nice value) to favor some pools over others. For example, the bucket index pool is usually much much smaller but important to recover first (e.g. might affect write latency as like issue #13104). > > > 2. pool level recovery op priority - currently we have a low priority for recovery op (by default it is 10 while client io's priority is 63), is it possible to have a pool setting to customized the priority on pool level. > > > > > > The purpose is to give some flexibility in terms of favor some pools over others when doing recovery, in our case using radosgw, we would like to favor bucket index pool as that is on the write path for all requests. > > > > I think this makes sense, and is analogous to > > > > https://github.com/ceph/ceph/pull/5922 > > > > which does per-pool scrub settings. I think the only real question is > > whether pg_pool_t is the right place to keep piling these parameters in, > > or whether we want some unstructured key/value settings or something. > > I aggree that adding a bunch of new rarely used fields to pg_pool_t > might not be a very good idea. Still storing these options here looks > convenient (accessing, updating...). What do you think if I add > something like this in pg_pool_t instead? > > typedef boost::variant<string,int,double> pool_opt_value_t; > typedef std::map<pool_opt_key_t,pool_opt_value_t> opts_t; > opts_t opts; > > (in reality I suppose it will be more compicated but will have > something like this in base). > > Usually opts will be empty or have only one or two settings, so it > will not consume much space. What do you think about this implementation, which adds a dictionary for pool options to pg_pool_t? https://github.com/ceph/ceph/pull/6081 Although #5922 has already been merged to master, I think it is still not late to change scrub intervals to be stored in options? > > Or where do you suggest to store them instead? > > BTW, I see we already have in pg_pool_t: > > map<string,string> properties; ///< OBSOLETE > > I wonder what it was supposed to be used for and why it is marked > obsolete? > > -- > Mykola Golub -- Mykola Golub -- 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
