Wednesday, September 5, 2012, 3:54:03 AM, you wrote: > Just for clarification: I did some tests and it seems the entries in the > "alternate vector" stored in the first "Doc" are different versions of the > same cached object?
Yes, see here: http://trafficserver.apache.org/docs/trunk/sdk/http-hooks-and-transactions/http-alternate-selection.en.html > As the cached object is represented with a linked list of fragments does > that mean that in order to serve a specific range from it we have to read > all fragments (presumably from disk) for the next_key until we get to the > signifficant fragment? No. The keys are computationally linked. Given a key for a fragment, the key for the next fragment is computed, not read. Therefore you can compute the key for fragment i from the key for fragment 0 without I/O. > From this description it seems to me that these "fragments inside a > fragment" resemble to the chunks you describe in your original e-mail. No, the chunks in my original e-mail would be subranges of these fragments. Current fragments are effectively all the same size except the last fragment. "Chunks" are not currently used for anything as they do not exist in the current implementation. If implemented as suggested they would be more notional, effectively being stored only as the validity bitmap per fragment. Disk I/O would continue to be per fragment. Fragments exist to limit disk I/O per I/O operation. The range acceleration was bolted on by adding the fragment offset tables. Hmmm, that would be a problem - how can you verify the entire range if it spans fragments, as there may by be missing chunks in the middle? You don't want to start serving and then discover a missing chunk. Ah, that's why the validity bitmaps would be stored in the fragment table, so all of that is available in memory before reading any fragments.
