Lines Matching full:blocks
10 // be stored as a series of blocks on a block-file. In any case, CacheAddr
18 // designed to store blocks of data of a given size. It is able to store data
19 // that spans from one to four consecutive "blocks", and it grows as needed to
20 // store up to approximately 65000 blocks. It has a fixed size header used for
21 // book keeping such as tracking free of blocks on the file. For example, a
22 // block-file for 1KB blocks will grow from 8KB when totally empty to about 64MB
23 // when completely full. At that point, data blocks of 1KB will be stored on a
24 // second block file that will store the next set of 65000 blocks. The first
32 // data_3), each one dedicated to store blocks of a given size. The number at
35 // There are two "special" types of blocks: an entry and a rankings node. An
41 // The files that store internal information for the cache (blocks and index)
109 // blocks (adding 256 bytes each time), up to 4 blocks (1024 - 32 - 1 chars).
165 // Bitmap to track used blocks on a block-file.
168 // A block-file is the file used to store information in blocks (could be
169 // EntryStore blocks, RankingsNode blocks or user-data blocks).
170 // We store entries that can expand for up to 4 consecutive blocks, and keep
171 // counters of the number of blocks available for each type of entry. For
172 // instance, an entry of 3 blocks is an entry of type 3. We also keep track of
183 int32 entry_size; // Size of the blocks of this file.
198 // and the second level stores blocks of 1 KB inside each child entry.
222 // Each child entry keeps track of all the 1 KB blocks that have been written
248 // is a parent entry), or used blocks (for child
254 // The number of blocks stored by a child entry.
