Hi Greg, Please find responses inline. With regards, Shishir > -----Original Message----- > From: Gregory Farnum [mailto:greg@xxxxxxxxxxx] > Sent: Wednesday, June 10, 2015 12:17 PM > To: Shishir Gowda > Cc: ceph-devel@xxxxxxxxxxxxxxx > Subject: Re: Ceph tier’ing enhancements blue print for jewel > > 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. > Sure, we will keep this in mind. > 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. > I agree that exposing these polices via RGW is prone to be abused, but it does provide users a fine gained control. Additionally, what we have in mind is an all flash array as cache tier, so it helps in reducing write amplification. > 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. Agreed, that is why using pools names are also mentioned, which would allow multiple tiers to exists. If the resolution/lookup of the pool fails, then we would fail the i/o, but in the future be moved to a default pool. > -Greg ________________________________ PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies). ��.n��������+%������w��{.n����z��u���ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
