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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
