INN commit: branches/2.5/storage/timecaf (README.CAF)
INN Commit
rra at isc.org
Mon Sep 7 08:28:11 UTC 2009
Date: Monday, September 7, 2009 @ 01:28:11
Author: iulius
Revision: 8624
Update the maximum size of a CAF.
Limits are 3.5GB or 262144 articles in a CAF.
Modified:
branches/2.5/storage/timecaf/README.CAF
------------+
README.CAF | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
Modified: README.CAF
===================================================================
--- README.CAF 2009-09-07 08:27:42 UTC (rev 8623)
+++ README.CAF 2009-09-07 08:28:11 UTC (rev 8624)
@@ -65,14 +65,18 @@
something like this. Each CAF file has a blocksize associated with it
(usually 512 bytes, but it can vary). The layout of a CAF file is as
follows:
- 1. Header (~52 bytes) containing information like low and high
+ 1. Header (~300 bytes) containing information like low and high
article numbers, amount of free space, blocksize.
2. Free space bitmap (size given by the FreeZoneTabSize field of the
-header).
- 3. CAFTOCENTs (CAF Table of Contents Entries), 1/article storable
+header). Its index is ~212 bytes (in fact, it is exactly between the end
+of the header and the end of the block). Its main part depends on the
+length of the index (n bits for the index => n bytes for the main free
+space bitmap, therefore ~1696 blocks, thus ~868KB). Consequently, the
+maximal length of a CAF file is ~3.5GB.
+ 3. CAFTOCENTs (CAF Table of Contents Entries), 1 per article storable
in the file. Each CAFTOCENT gives the article's size, creation time,
and offset in the CAF file. Usually space is alloted in the CAF file
-for 64K CAFTOCENTs, even if the # of articles in the CAF file is
+for 262144 CAFTOCENTs, even if the # of articles in the CAF file is
nowhere near that amount. The unused CAFTOCENTs are all zeros, and
this means CAF files are almost always sparse.
4. Articles, always stored starting at blocksize boundaries.
@@ -95,7 +99,8 @@
First there is an 'index' bitmap which tells which blocks of the 'main' bitmap
have free blocks listed in them, and then a 'main' bitmap which tells whether
the data blocks are in use or free. This setup means that we can have
-bitmaps for CAF files as large as 8GB, while still being able to find free
+bitmaps for CAF files as large as 8GB (in fact, it is now about 3.5GB, see
+computation above -- note by Julien Elie), while still being able to find free
space by only reading the 'index' bitmap and one block of the 'main' bitmap.
(Previous versions of the CAF code had just a 'main' bitmap and scaled the
blocksize up when CAF files got large; this became rather, um, non-optimal
More information about the inn-committers
mailing list