> > > No. The keys are computationally linked. Given a key for a fragment, the > key for the next fragment is computed, not read.
OK, I think I found the way the next_key is computed from a given key. > Therefore you can compute the key for fragment i from the key for fragment > 0 without I/O. > Are all Doc structures of the same size? If they differ in size and we do not have somewhere in RAM (or in the first fragment) each of their sizes how can we get away without any I/O for the non relevant Docs when serving a range request? > 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. > So the fragments table entry will be augmented with a new uint64_t field which holds the chunk validity information. But after computing all the necessary "Doc" structures for satisfying a range request they still have to be read from disk (not the content, just the first part containing the fragments table) to check for chunk validity. Only when we know we have the complete range valid we may serve the range from the cache. Thank you very much for pointing me to the "Traffic Server Programming Guide"!
