Details
Major - P3 Description
When compacting a collection that is actively being written it is possible that the collection is larger at the completion of compaction than when it started; I assume that this is an expected outcome. In this case the operation returns a negative number for bytesFreed:
{
|
"bytesFreed" : -339968,
|
"ok" : 1,
|
"$clusterTime" : {
|
"clusterTime" : Timestamp(1614690587, 925),
|
"signature" : {
|
"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
|
"keyId" : NumberLong(0)
|
}
|
},
|
"operationTime" : Timestamp(1614690587, 898)
|
}
|
Whereas an absurdly large value is logged for freedBytes:
{"t":{"$date":"2021-03-02T08:09:47.634-05:00"},"s":"I", "c":"STORAGE", "id":20286, "ctx":"conn24","msg":"Compact end","attr":{"namespace":"test.c","freedBytes":18446744073709211648}}
|
It looks like compactCollection is incorrectly treating the negative signed value as unsigned when it logs it.
Possibly both values should be logged as 0, since logging a negative value may make it appear that compact is malfunctioning.
Also, it would be good to make the command result and the log statement consistent; suggest changing the log statement to use "bytesFreed" as it seems less likely that users will be affected by changing the log statement than by changing the command return.