On Wed, 26 Feb 2014, Gregory Farnum wrote: > We/you/somebody need(s) to sit down and decide on what kind of > interface we want to actually expose to users for working with caching > pools. What we have right now is very flexible, but it's hard to test > all the combinations and it's easy for users to get themselves into > trouble. > I know we've in the past discussed making all the configuration > options into a single "create cache pool" command that accepts > whatever we're interested in, and I think that's the model we want to > go towards right now. But we're running out of time to make that > change given the release deadline and the documentation that needs to > be generated (eg http://tracker.ceph.com/issues/7547). Right now the sequence is: ceph osd pool create cache $num_pgs ceph osd tier add base cache ceph osd tier cache-mode cache writeback ceph osd tier set-overlay base cache ceph osd pool set cache hit_set_type bloom ceph osd pool set cache hit_set_count 8 ceph osd pool set cache hit_set_period 60 ceph osd pool set cache target_max_objects 5000 (modulo some sane defaults, and the target size) I mostly like the flexibility this presents and don't forsee any major problems, but nevertheless I agree that a friendly interface is safer to advertise and, well, friendlier. How about: ceph osd pool create cache $num_pgs (I think think this should be a separate step since users will want/need to adjust the crush rule and so forth to put this on the right devices *before* it gets set as an overlay and gets hammered by the existing pool's workload.) Then ceph osd tier add-cache base cache which would do the other 3 tier steps and set some sane hit_set defaults. What do you think? Separately: 1- I'm not sure what the default target size should be set to; maybe a default of 10000 objects or something? I think it should be *something*. 2- I think we need to bite the bullet and make a 'ceph df' function that figures out how much space is available on a per-pool basis. It would: - figure out which osds are toched by the rules for each pool, and - sum up only those osds' usages - divide by the replication factor or EC storage overhead If there target_max_* values aren't set for the pool, this could be used instead, by periodically filling in a pg_pool_t approximate_capacity type field. Of course, for multiple pools this is double counting free space, but for the purposes of the cache agent it is still perfectly usable as a target for controlling when the agent kicks into gear. It would also be very nice for users. (Hmm, perhaps I should write this up in a blueprint!) 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
