SimpleCache: merge the first and second stream in one file

net/disk_cache/simple/simple_entry_format.h

Index: net/disk_cache/simple/simple_entry_format.h
diff --git a/net/disk_cache/simple/simple_entry_format.h b/net/disk_cache/simple/simple_entry_format.h
index d06ab1139c53980c54a50347c0bb36279d6a3f28..4df78f376d601c32cc44d352c52677019a065778 100644
--- a/net/disk_cache/simple/simple_entry_format.h
+++ b/net/disk_cache/simple/simple_entry_format.h
@@ -19,17 +19,23 @@ namespace disk_cache {
 const uint64 kSimpleInitialMagicNumber = GG_UINT64_C(0xfcfb6d1ba7725c30);
 const uint64 kSimpleFinalMagicNumber = GG_UINT64_C(0xf4fa6f45970d41d8);
 
-// A file in the Simple cache consists of a SimpleFileHeader followed
-// by data.
+// A file containing stream 0 and stream 1 in the Simple cache consists of:
+//   - a SimpleFileHeader.
+//   - the key.
+//   - the data from stream 1.
+//   - a SimpleFileEOF record for stream 1.
+//   - the data from stream 0.
+//   - a SimpleFileEOF record for stream 0.
 
-// A file in the Simple cache consists of:
+// A file containing stream 2 in the Simple cache consists of:
 //   - a SimpleFileHeader.
 //   - the key.
 //   - the data.
 //   - at the end, a SimpleFileEOF record.
-const uint32 kSimpleVersion = 4;
+const uint32 kSimpleVersion = 5;
 
-static const int kSimpleEntryFileCount = 3;
+static const int kSimpleEntryFileCount = 2;
+static const int kSimpleEntryStreamCount = 3;
 
 struct NET_EXPORT_PRIVATE SimpleFileHeader {
   SimpleFileHeader();
@@ -38,6 +44,10 @@ struct NET_EXPORT_PRIVATE SimpleFileHeader {
   uint32 version;
   uint32 key_length;
   uint32 key_hash;
+  // Only used in the file containing stream 0 and stream 1. For stream 2, the
+  // size is computed from the file size.
+  uint32 stream_0_size;

[gavinp, 2013/09/10 22:20:49]

I'm not sure that storing explicit sizes is great. Now, what do we do if the
file size and the stream sizes are mutually inconsistent?

We can avoid this by storing offsets. And the offset of stream 1 is pretty easy
to store: it's 0.

As well, storing the stream 0 size means we're mutating this header every time
that stream 0 changes size.

I propose: we store the stream 0 offset in a signed int. Negative means from
EOF, positive means from beginning. The first time we write the header, we don't
know stream 1 size, but we do know stream 0, so we write a negative offset. The
first time we update the headers, we can write in a positive offset (we know the
stream 1 size), and then we aren't rewriting the header ever.

That's more complex though than just always storing the size of stream 1 here
(might as well always make it negative, just so the upgrade is easier if we do
the tricky thing). And it avoids all these weird inconsistencies from the
explicit sizes.

[clamy, 2013/09/11 12:46:21]

I don't really like the idea of having an offset taken from different things
based on its sign. I find it too complicated, not to mention that the first time
we write the header we don't know the size of stream 0 (since it is in Create).
The other time (on Close) we know the size of both streams, so which one we
choose matters little. I would also prefer to store the size explicitly, rather
than an offset, since we already store the key size.

As to whether store stream 0 or stream 1 size, if we expect stream 1 size to
vary less, it would be better to store stream 1. Then rewrite the header only if
stream 1 size varies.

[gavinp, 2013/09/11 14:22:10]

If we write stream 1 size, we're rewriting the header every time we close an
entry. The most common case for a cache entry is to never be used, so
unfortunate to create extra IO for that case.

The offset from different things based on sign probably is too complicated;
sure.

Could we store the size of stream 0 in the footer?

[clamy, 2013/09/16 15:01:17]

Done.

+  uint32 stream_1_size;
 };
 
 struct SimpleFileEOF {