Saturday, August 10, 2013, 8:49:45 PM, you wrote: > 1) Is the quality the same as a "tier level" ? If so, 4,294,967,296 different > tiers seems incredibly excessive.
Yes. We thought it more hassle than benefit to restrict the quality value to less than 32 bits. It does give some flexibility in the choice of values if a user wants to encode more than a simple linear sequence in them. > 2) The Oracle logic doesn't seem to include a feature to evict from one tier > when the object gets "promoted" to a higher tier. I don't know if this is > required, but it seems reasonable to think that if I have RAM + SSD + Disk, > once an object gets stored in the RAM cache, it's enough to keep it in > rotational disk for the time being. This was discussed and I was convinced that explicit eviction wasn't that useful. Of course, behind the scenes the oracle could evict when it returns a WRITE or RW for some other tier. > 3) How are the different cache tiers implemented? Are they all using existing > disk cache layouts (except for RAM cache)? I guess if that's the case, #2 > above might not make a whole lot of sense (it'll churn out anyways in the > cyclone). The same as the current volumes. The goal was to make the current layout and behavior identical to a tiered system with only one tier value, because that is what a user gets if they do not specify any tier values. > 4) It feels like we should redo the existing RAM + disk cache such that the > default is two tiers and the promotion algorithms between the two tiers maps > to our LRU or CFLUS implementations (but using this concept of tiers). That > would imply that a cache tier can choose between at least 3 different types > cache layouts. I need to think about it in more detail, but my view is that you could do this in the proposed design by an appropriate implementation of the oracle. Presumably we would provide reference oracle implementations that did this.
