Compaction

Understanding Bytes Written

When broadcasting trees out to a cluster, before they download your tree, they check the tree size. Instead of iterating over the whole tree to get the size, CrissCross keeps track of how many bytes are written to disk as your tree is created. This includes the node metadata so it is larger than the inserted data size.

You can find this information by bytes_written

$ crisscross put "" "hello" "world"
2UPmgiyB93RNrPHYMrX3Hba18fuNYW6aCNC9dyd3pk9qXhB
$ crisscross bytes_written 2UPmgiyB93RNrPHYMrX3Hba18fuNYW6aCNC9dyd3pk9qXhB
125

However when data is deleted, bytes_written does not go down, its monotonic. As you insert new nodes, the old leaves and headers expire and are set to be deleted as configured in their TTL and will be deleted on disk. However the bytes_written will not change. bytes_written will always be larger than what is actually stored on disk. Therefore peers can reject storing your trees because when they check, your tree looks larger than it is.

Compact

To fix this call the compact function to return a new tree.

$ crisscross put "" "hello" "world"
2UPmgiyB93RNrPHYMrX3Hba18fuNYW6aCNC9dyd3pk9qXhB
$ crisscross put "2UPmgiyB93RNrPHYMrX3Hba18fuNYW6aCNC9dyd3pk9qXhB" "hello2" "world2"
2UPcwQJXpYXSqeABKqc8ZkMhYdM8UVDKbNqCQXbxxB6LNfh
$ crisscross bytes_written 2UPcwQJXpYXSqeABKqc8ZkMhYdM8UVDKbNqCQXbxxB6LNfh
193
$ crisscross delete 2UPcwQJXpYXSqeABKqc8ZkMhYdM8UVDKbNqCQXbxxB6LNfh "hello2"
2UPiRyyJv4vdDqrEwBQitD53Fbwcuih7VDDhF2UxdzXvoBd
$ crisscross bytes_written 2UPiRyyJv4vdDqrEwBQitD53Fbwcuih7VDDhF2UxdzXvoBd
243
$ crisscross compact 2UPiRyyJv4vdDqrEwBQitD53Fbwcuih7VDDhF2UxdzXvoBd
NewHash: 2UPqQ7AhWj3TqVNfX835E5mbrJKHP5cTLfj2bWRi4EGfLto
NewSize: 135 bytes
OldSize: 243 bytes