On Aug 10, 2013, at 7:49 PM, Leif Hedstrom <[email protected]> wrote:
>
> On Aug 10, 2013, at 6:15 PM, "Alan M. Carroll" <[email protected]>
> wrote:
>
>> All;
>>
>> I have added a new section to the documentation, 'arch', for "Architecture".
>> Currently it contains just my writings on the cache implementation but
>> others are of course STRONGLY encouraged to contribute. This should not be
>> API level stuff but design / architecture stuff that explores the concepts,
>> designs, and interactions of components of ATS. I think it is also a good
>> place for writing up design suggestions for future implementation.
>
> Very cool. A few questions on the cache tiering:
I'm a little uncertain on this:
"When a request is received from a client volume assignment is done in
parallel for each tier quality".
This seems like it could be potentially expensive. For example, an object that
is in all cache tiers would have to examine that object in the cache before
saying it's "readable" or not, right? So lets say an object is in SSD and
rotational disk, and the Oracle queries this in parallel, it'll cause us to
become bound by the speed of the rotational disk, no? The risk of course is
that you kill the I/O on the slow rotational disk long before the SSD. (An SSD
can do maybe 20,000 lookups /sec, a rotational disk can do 300/sec, yet you
theoretically hammer both with the same IOPS).
It feels like these lookups should be done sequential, or at least staggered,
such that a fast device (e.g. SSD) has a chance to short circuit the lookup
process. Maybe the quality number can be used as a hint to how fast that tier
is: high 16-bit becomes a metric value indicating response time in micro
seconds, low 16-bit is the priority when response times are "similar".
Cheers,
-- leif
