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.