Hi Robert,

 I am not quite sure if I get your question correct, but what I understand is that you want the inbound writes to land on the cache tier, which presumably would be on a faster media, possibily a ssd.

From there you would want it to trickle down to the base tier, which is a EC pool hosted on HDD.

Some of the pointers I have :-

It is better to have seperate media for base and cache , HDD and SSD respectively.

If the intent is never to promote to cache tier on Read, you could set it to a high number such as 3, and at the same time, Make the bloom filter window small.( This basically translates into if the object has been read X number of times in past y seconds)

Keep in mind the larger the window, the more the size of the bloom filter, and hence you would see a increase in osd memory usgae.

I have patch somewhere lurking which disables the promotes, let me check on the same, if this is for a specific case.

If your intent is to have a constant decay rate from the Cache tier to the base tier, here is what you could do.:-

1.Set the Max Objects on the Cache tier TO X 

2.Set the Max Size to say Y, this would be normally 60-70 percent of the total cache tier capacity.

3.The flushes would start happening on the first trigger of the above thresholds.

4. You could set the evict age roughly double the time, you expect the data will hit the base tier.

5.Lastly have you tried running cosbench or any related tool, to qualify the IOPS of your base tier with EC enabled, you may. Or require the cache tier at all.

6. There are substantial overheads of a cache tier maintenance, the major being absence of throttles on how the flush happens.

7.A thundering herd of write requests can cause a huge amount of flush to happen to the base tier.

8.IMHO it is suitable and predictable for loads where number of ingress requests can be predicted and there is some kind of rate limiting on the same.