In practice the fragments are not all the same size. The sizing logic is a bit sloppy because it was not considered important at the time to get the fragments consistently sized (why does it matter if all fragments will be read on a cache hit?). When I put in the range acceleration I didn't want to deal with that change as well. With the POC update the fragment table is still needed, even though the fragments for an object are consistent sized, to hold state information about the fragments.
On Sunday, June 4, 2017, 11:24:52 PM CDT, Anh Le Duc (2) <anh...@vng.com.vn> wrote: @Alan: I saw your answer for my issue #2023 <https://github.com/apache/trafficserver/issues/2023>. To handle range requests, we must efficiently know which fragments to read. By using fragment tables, we can achieve that purpose. For example: if we serve a range request of bytes 1000-2000, with fragment tables, we know the Nth fragment (from the current one) containing requested data. By continuously applying hash functions on the request's key N times, we may effectively locate the fragment. My question is: if we split a specific object into multiple fragments having the same size, are fragment tables useless? Because we can quickly have: 1000/fragmentSize <= N = 2000 / fragmentSize
