Disk cache: Reference CL for the implementation of file format version 3.

net/disk_cache/disk_format.h

Index: net/disk_cache/disk_format.h
===================================================================
--- net/disk_cache/disk_format.h	(revision 199883)
+++ net/disk_cache/disk_format.h	(working copy)
@@ -5,9 +5,9 @@
 // The cache is stored on disk as a collection of block-files, plus an index
 // file plus a collection of external files.
 //
-// Any data blob bigger than kMaxBlockSize (net/addr.h) will be stored on a
-// separate file named f_xxx where x is a hexadecimal number. Shorter data will
-// be stored as a series of blocks on a block-file. In any case, CacheAddr
+// Any data blob bigger than kMaxBlockSize (disk_cache/addr.h) will be stored in
+// a separate file named f_xxx where x is a hexadecimal number. Shorter data
+// will be stored as a series of blocks on a block-file. In any case, CacheAddr
 // represents the address of the data inside the cache.
 //
 // The index file is just a simple hash table that maps a particular entry to
@@ -15,18 +15,8 @@
 // by the cache entry.
 //
 // The last element of the cache is the block-file. A block file is a file
-// designed to store blocks of data of a given size. It is able to store data
-// that spans from one to four consecutive "blocks", and it grows as needed to
-// store up to approximately 65000 blocks. It has a fixed size header used for
-// book keeping such as tracking free of blocks on the file. For example, a
-// block-file for 1KB blocks will grow from 8KB when totally empty to about 64MB
-// when completely full. At that point, data blocks of 1KB will be stored on a
-// second block file that will store the next set of 65000 blocks. The first
-// file contains the number of the second file, and the second file contains the
-// number of a third file, created when the second file reaches its limit. It is
-// important to remember that no matter how long the chain of files is, any
-// given block can be located directly by its address, which contains the file
-// number and starting block inside the file.
+// designed to store blocks of data of a given size. For more details see
+// disk_cache/disk_format_base.h
 //
 // A new cache is initialized with four block files (named data_0 through
 // data_3), each one dedicated to store blocks of a given size. The number at
@@ -57,11 +47,10 @@
 
 #include "base/basictypes.h"
 #include "net/base/net_export.h"
+#include "net/disk_cache/disk_format_base.h"
 
 namespace disk_cache {
 
-typedef uint32 CacheAddr;
-
 const int kIndexTablesize = 0x10000;
 const uint32 kIndexMagic = 0xC103CAC3;
 const uint32 kCurrentVersion = 0x20000;  // Version 2.0.
@@ -159,104 +148,6 @@
 
 COMPILE_ASSERT(sizeof(RankingsNode) == 36, bad_RankingsNode);
 
-const uint32 kBlockMagic = 0xC104CAC3;
-const int kBlockHeaderSize = 8192;  // Two pages: almost 64k entries
-const int kMaxBlocks = (kBlockHeaderSize - 80) * 8;
-
-// Bitmap to track used blocks on a block-file.
-typedef uint32 AllocBitmap[kMaxBlocks / 32];
-
-// A block-file is the file used to store information in blocks (could be
-// EntryStore blocks, RankingsNode blocks or user-data blocks).
-// We store entries that can expand for up to 4 consecutive blocks, and keep
-// counters of the number of blocks available for each type of entry. For
-// instance, an entry of 3 blocks is an entry of type 3. We also keep track of
-// where did we find the last entry of that type (to avoid searching the bitmap
-// from the beginning every time).
-// This Structure is the header of a block-file:
-struct NET_EXPORT_PRIVATE BlockFileHeader {
-  BlockFileHeader();
-
-  uint32          magic;
-  uint32          version;
-  int16           this_file;    // Index of this file.
-  int16           next_file;    // Next file when this one is full.
-  int32           entry_size;   // Size of the blocks of this file.
-  int32           num_entries;  // Number of stored entries.
-  int32           max_entries;  // Current maximum number of entries.
-  int32           empty[4];     // Counters of empty entries for each type.
-  int32           hints[4];     // Last used position for each entry type.
-  volatile int32  updating;     // Keep track of updates to the header.
-  int32           user[5];
-  AllocBitmap     allocation_map;
-};
-
-COMPILE_ASSERT(sizeof(BlockFileHeader) == kBlockHeaderSize, bad_header);
-
-// Sparse data support:
-// We keep a two level hierarchy to enable sparse data for an entry: the first
-// level consists of using separate "child" entries to store ranges of 1 MB,
-// and the second level stores blocks of 1 KB inside each child entry.
-//
-// Whenever we need to access a particular sparse offset, we first locate the
-// child entry that stores that offset, so we discard the 20 least significant
-// bits of the offset, and end up with the child id. For instance, the child id
-// to store the first megabyte is 0, and the child that should store offset
-// 0x410000 has an id of 4.
-//
-// The child entry is stored the same way as any other entry, so it also has a
-// name (key). The key includes a signature to be able to identify children
-// created for different generations of the same resource. In other words, given
-// that a given sparse entry can have a large number of child entries, and the
-// resource can be invalidated and replaced with a new version at any time, it
-// is important to be sure that a given child actually belongs to certain entry.
-//
-// The full name of a child entry is composed with a prefix ("Range_"), and two
-// hexadecimal 64-bit numbers at the end, separated by semicolons. The first
-// number is the signature of the parent key, and the second number is the child
-// id as described previously. The signature itself is also stored internally by
-// the child and the parent entries. For example, a sparse entry with a key of
-// "sparse entry name", and a signature of 0x052AF76, may have a child entry
-// named "Range_sparse entry name:052af76:4", which stores data in the range
-// 0x400000 to 0x4FFFFF.
-//
-// Each child entry keeps track of all the 1 KB blocks that have been written
-// to the entry, but being a regular entry, it will happily return zeros for any
-// read that spans data not written before. The actual sparse data is stored in
-// one of the data streams of the child entry (at index 1), while the control
-// information is stored in another stream (at index 2), both by parents and
-// the children.
-
-// This structure contains the control information for parent and child entries.
-// It is stored at offset 0 of the data stream with index 2.
-// It is possible to write to a child entry in a way that causes the last block
-// to be only partialy filled. In that case, last_block and last_block_len will
-// keep track of that block.
-struct SparseHeader {
-  int64 signature;          // The parent and children signature.
-  uint32 magic;             // Structure identifier (equal to kIndexMagic).
-  int32 parent_key_len;     // Key length for the parent entry.
-  int32 last_block;         // Index of the last written block.
-  int32 last_block_len;     // Lenght of the last written block.
-  int32 dummy[10];
-};
-
-// The SparseHeader will be followed by a bitmap, as described by this
-// structure.
-struct SparseData {
-  SparseHeader header;
-  uint32 bitmap[32];        // Bitmap representation of known children (if this
-                            // is a parent entry), or used blocks (for child
-                            // entries. The size is fixed for child entries but
-                            // not for parents; it can be as small as 4 bytes
-                            // and as large as 8 KB.
-};
-
-// The number of blocks stored by a child entry.
-const int kNumSparseBits = 1024;
-COMPILE_ASSERT(sizeof(SparseData) == sizeof(SparseHeader) + kNumSparseBits / 8,
-               Invalid_SparseData_bitmap);
-
 }  // namespace disk_cache
 
 #endif  // NET_DISK_CACHE_DISK_FORMAT_H_