Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(70)

Unified Diff: net/disk_cache/v3/disk_format_v3.h

Issue 14991008: Disk cache: Add base files for implementation of file format version 3. (Closed) Base URL: svn://svn.chromium.org/chrome/trunk/src/
Patch Set: Rebase attempt 2 Created 7 years, 7 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View side-by-side diff with in-line comments
Download patch
Index: net/disk_cache/v3/disk_format_v3.h
===================================================================
--- net/disk_cache/v3/disk_format_v3.h (revision 0)
+++ net/disk_cache/v3/disk_format_v3.h (working copy)
@@ -60,24 +60,8 @@
namespace disk_cache {
-typedef uint32 CacheAddr;
-
-const int kIndexTablesize = 0x10000;
-const uint32 kIndexMagic = 0xC103CAC3;
const uint32 kCurrentVersion = 0x20000; // Version 2.0.
-struct LruData {
- int32 pad1[2];
- int32 filled; // Flag to tell when we filled the cache.
- int32 sizes[5];
- CacheAddr heads[5];
- CacheAddr tails[5];
- CacheAddr transaction; // In-flight operation target.
- int32 operation; // Actual in-flight operation.
- int32 operation_list; // In-flight operation list.
- int32 pad2[7];
-};
-
// Header for the master index file.
struct NET_EXPORT_PRIVATE IndexHeader {
IndexHeader();
@@ -104,6 +88,19 @@
// by header.table_len.
};
+// Possible states for a given entry.
+enum EntryState {
+ ENTRY_NORMAL = 0,
+ ENTRY_EVICTED, // The entry was recently evicted from the cache.
+ ENTRY_DOOMED // The entry was doomed.
+};
+
+// Flags that can be applied to an entry.
+enum EntryFlags {
+ PARENT_ENTRY = 1, // This entry has children (sparse) entries.
+ CHILD_ENTRY = 1 << 1 // Child entry that stores sparse data.
+};
+
// Main structure for an entry on the backing storage. If the key is longer than
// what can be stored on this structure, it will be extended on consecutive
// blocks (adding 256 bytes each time), up to 4 blocks (1024 - 32 - 1 chars).
@@ -131,132 +128,6 @@
const int kMaxInternalKeyLength = 4 * sizeof(EntryStore) -
offsetof(EntryStore, key) - 1;
-// Possible states for a given entry.
-enum EntryState {
- ENTRY_NORMAL = 0,
- ENTRY_EVICTED, // The entry was recently evicted from the cache.
- ENTRY_DOOMED // The entry was doomed.
-};
-
-// Flags that can be applied to an entry.
-enum EntryFlags {
- PARENT_ENTRY = 1, // This entry has children (sparse) entries.
- CHILD_ENTRY = 1 << 1 // Child entry that stores sparse data.
-};
-
-#pragma pack(push, 4)
-// Rankings information for a given entry.
-struct RankingsNode {
- uint64 last_used; // LRU info.
- uint64 last_modified; // LRU info.
- CacheAddr next; // LRU list.
- CacheAddr prev; // LRU list.
- CacheAddr contents; // Address of the EntryStore.
- int32 dirty; // The entry is being modifyied.
- uint32 self_hash; // RankingsNode's hash.
-};
-#pragma pack(pop)
-
-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_

Powered by Google App Engine
This is Rietveld 408576698