On Tue, Jun 9, 2015 at 7:52 PM, Shishir Gowda <Shishir.Gowda@xxxxxxxxxxx> wrote: > Hi All, > > We have uploaded the blueprint for the enhancements we are proposing for ceph tier’ing functionality for Jewel release @ > > http://tracker.ceph.com/projects/ceph/wiki/Tiering-enhacement > > Soliciting comments/feedback for the same. By and large this looks pretty sensible to me in a quick read. The things I noticed: 1) There's a reference to the policy function getting passed in data about how full the pool is. Note that while we expose stuff to cache pool users in terms of pools, in the internal implementations the flushing functions are based on how full the local PG is — that's because we don't have any up-to-date information about the global pool (and we really can't). I imagine just substituting PG for pool in your description should work, but if not that's something to address. 2) Are you sure you want to expose these policies via RGW? That sounds both excessively complicated (from the UI perspective) and liable to abuse by users. Plus it seems a little redundant — I could imagine people wanting the very fastest storage, but then they should just store those objects in RGW buckets which are stored on pools with appropriate policies (I forget what this mechanism is called, but there's some sort of placement thing when creating buckets). Otherwise the enhancements for things like direct-read-from-EC-shards etc seem to cover RGW's performance needs pretty well. 3) While a bunch of the docs and possibly some of the code imply that you have a single cache and a single base tier, I think in general you can set up tier chains. We want to preserve that, so the $CACHE and $BASE language used in the tier functions needs to be capable of that. -Greg -- 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
