logd: always compress SerializedLogChunk in FinishWriting()
When calculating the space used for pruning, if a log chunk is compressed, that size is used otherwise the uncompressed size is used. This is intended to reach a steady state where 1/4 of the log buffer is the uncompressed log chunk that is being written to and the other 3/4 of the log buffer is compressed logs. If we wait until there are no readers referencing the log chunk before compressing it, we end up with 2 uncompressed logs (the one that was just filled, that readers are still referencing, and the new one that was allocated to fit the most recent log), which take up 1/2 of the log buffer's allotted size and will thus cause prune to delete more compressed logs than it should. Instead, we should always compress the log chunks in FinishWriting() such that the compressed size will always be used for log chunks other than the one that is not actively written to. Decompressed logs due to readers are ephemeral by their nature and thus don't add to the log buffer size for pruning. Test: observe that log buffers can be filled in the presence of a reader. Change-Id: Ie21ccff032e41c4a0e51710cc435c5ab316563cb
Loading
Please register or sign in to comment