Cache truncation bug on aborted appends

[Bron Gondwana]

Hi all,

Cyrus stores the end of the cache file before starting an
append operation so that it can truncate back to that point
if the append is aborted.

Unfortunately, it actually stores cache_len rather than
cache_size.  That sort of sucks, because cache_len is
rounded up by quite a bit to allow "slop".  As the cache
file gets bigger, the slop gets bigger too, and you wind
up with a whole pile of zero blocks in your cache file,
making it (even if sparse) somewhat massive.

Oh, and the bogus record(s) that you wrote are going to
still be (possibly only partially) in the file, because
the truncate will either be past them, or in the middle
of them.

This is exacerbated by the fact that duplicate suppression
seems to need to write to the cache file _before_ it decides
not to accept the message!

The attached patch fixes the issue, adds a comment, and
renames the temporary variable to reflect the value it's
actually storing.

Wes/Ken, please apply to CVS for the next stable release.

Everyone else, I recommend you apply this patch.  We have
had to reconstruct the occasional mailbox as their cache file
size spirals out of control and the process hits memory
limits trying to map it.

Bron.
-- 
  Bron Gondwana
  brong at fastmail.fm

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cyrus-truncate-length-2.3.13.diff
Type: text/x-patch
Size: 1353 bytes
Desc: not available
Url : http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20081205/c17666ab/attachment.bin