Hello

If I understand correctly the issue is about filesystem space not freeing immediately after drop.

This is probably because MongoDB has two phase drop implementation. At first phase collection and its indexes are removed from metadata (but files are still preserved). At second phase files are removed from the filesystem. In the most common case second phase is deferred until the next checkpoint. By default MongoDB does checkpoints each 60 seconds.

That means it does not matter if you recreate collection with the same name or not. In any case old collection’s files will be removed after up to 60 seconds delay.

Please let us know if this corresponds to your observations.

This is an expected behavior in MongoDB. MongoDB seldom returns disk space to the operating system during deleting, these disk pages are marked dirty and reserved for writing in the future. The compact command lets WiredTiger return this space. (like PostgreSQL’s Vacuum). Note, that the compact command needs to be executed on every node in the cluster. Alternatively, you can resync a replicate set member (what you actually did by restarting the node).

See also MongoDB docs.

We need to investigate this issue and understand the behavior, explicitly what happens when the new collection with the same name is not created, is the space remains allocated or not?

than we are able to decide how to threat the bug.