Thank you for taking the time to draw that diagram! Looking at this diagram and the code some things are not clear for me:
1. Is there a one to many relation between a cached object and a Doc structure? In other words: many Doc structure hold the data for a cached object? The diagram says that only "first Doc in the chain" will contain the alternate information vector. This suggests there are many Doc structure associated to a cached object. 2. A Doc structure contains a table of fragments which are represented as uint64_t offsets. I understand that you plan to move this table to the alternate information. But it is not clear to me where are these offsets pointing into currently? Where is data with offset zero held? Best regards, Bogdan Graur On Wed, Aug 29, 2012 at 2:58 PM, Alan M. Carroll < a...@network-geographics.com> wrote: > Kinda sorta of. I have made a simple diagram with some of this information: > > http://people.apache.org/~amc/ats-cache-layout.jpg > > which you might find useful. The proposed change would be quite similar to > the existing cache structure but would have a couple of major differences - > > 1) Support having "fallow" fragments. The current logic requires all > fragments to be present in the cache and cannot detect or handle missing > fragments. > > 2) Subdividing each fragment in to chunks. All of that would be new. > > This would also require moving the fragment offset data in to the > alternate information but I already have a patch for that which will be > landing on trunk Real Soon Now. > > Tuesday, August 28, 2012, 1:14:48 PM, you wrote: > > > This model of representing a cached object indeed allows holding only > > partial data for the resource. > > > Is this the current way a cached object is currently represented in TS? > >
