# .dropCollection() potential bug **URL:** \ **Category:** Percona Server for MongoDB\ **Created:** [June 25, 2024, 9:31pm UTC](https://forums.percona.com/t/dropcollection-potential-bug/31241 "2024-06-25T21:31:23Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![rkamath](https://avatars.discourse-cdn.com/v4/letter/r/b38774/32.png) [@rkamath](https://forums.percona.com/u/rkamath)\ **Post date:** [June 25, 2024, 9:31pm UTC](https://forums.percona.com/t/dropcollection-potential-bug/31241/1 "2024-06-25T21:31:23Z")
There seems to be a bug where doing .dropCollection() and then immediately recreating the collection does not seem to release space back to OS. This was encountered where a collection was dropped and immediately remade with the same indexes in order to free space. But this then required a server restart in order for the space to be released back to the OS. The MongoDB server was in a replica set. Is this a known bug? ---
**Author:** ![Ivan\_Groenewold](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/ivan_groenewold/32/6299_2.png) [@Ivan\_Groenewold](https://forums.percona.com/u/Ivan_Groenewold)\ **Post date:** [June 26, 2024, 12:03pm UTC](https://forums.percona.com/t/dropcollection-potential-bug/31241/2 "2024-06-26T12:03:28Z")
It might be a bug. Please open a report at [jira.percona.com](http://jira.percona.com) with details so the dev team can take a look ---
**Author:** ![radoslaw.szulgo](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/radoslaw.szulgo/32/17315_2.png) [@radoslaw.szulgo](https://forums.percona.com/u/radoslaw.szulgo)\ **Post date:** [July 16, 2024, 11:38am UTC](https://forums.percona.com/t/dropcollection-potential-bug/31241/3 "2024-07-16T11:38:21Z")
hi @rkamath have you been able to create a bug for this? ---
**Author:** ![rkamath](https://avatars.discourse-cdn.com/v4/letter/r/b38774/32.png) [@rkamath](https://forums.percona.com/u/rkamath)\ **Post date:** [July 16, 2024, 2:18pm UTC](https://forums.percona.com/t/dropcollection-potential-bug/31241/4 "2024-07-16T14:18:55Z")
[https://perconadev.atlassian.net/browse/PSMDB-1480](https://perconadev.atlassian.net/browse/PSMDB-1480) I created it here although I’m not sure if this was the right place or not. ---
**Author:** ![radoslaw.szulgo](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/radoslaw.szulgo/32/17315_2.png) [@radoslaw.szulgo](https://forums.percona.com/u/radoslaw.szulgo)\ **Post date:** [July 16, 2024, 2:52pm UTC](https://forums.percona.com/t/dropcollection-potential-bug/31241/5 "2024-07-16T14:52:56Z")
Perfect! It’s in the right project - thank you - I was not able to find it. I’ll provide you an update as soon as I can. ---
**Author:** ![radoslaw.szulgo](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/radoslaw.szulgo/32/17315_2.png) [@radoslaw.szulgo](https://forums.percona.com/u/radoslaw.szulgo)\ **Post date:** [July 23, 2024, 9:14am UTC](https://forums.percona.com/t/dropcollection-potential-bug/31241/6 "2024-07-23T09:14:32Z")
@rkamath - 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](https://www.mongodb.com/docs/manual/faq/storage/#how-do-i-reclaim-disk-space-in-wiredtiger-): > ### How do I reclaim disk space in WiredTiger? > > The WiredTiger storage engine maintains lists of empty records in data files as it deletes documents. This space can be reused by WiredTiger, but will not be returned to the operating system unless under very specific circumstances. > > The amount of empty space available for reuse by WiredTiger is reflected in the output of [`db.collection.stats()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.stats/#mongodb-method-db.collection.stats) under the heading `wiredTiger.block-manager.file bytes available for reuse`. > > To allow the WiredTiger storage engine to release this empty space to the operating system, you can de-fragment your data file. This can be achieved by [resyncing a replica set member](https://www.mongodb.com/docs/manual/tutorial/resync-replica-set-member/#std-label-resync-replica-member) or using the [`compact`](https://www.mongodb.com/docs/manual/reference/command/compact/#mongodb-dbcommand-dbcmd.compact) command. ---
**Author:** ![Igor\_Solodovnikov](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/igor_solodovnikov/32/1265_2.png) [@Igor\_Solodovnikov](https://forums.percona.com/u/Igor_Solodovnikov)\ **Post date:** [July 23, 2024, 1:58pm UTC](https://forums.percona.com/t/dropcollection-potential-bug/31241/7 "2024-07-23T13:58:41Z")
Hello @rkamath 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 every 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. ---
**Author:** ![rkamath](https://avatars.discourse-cdn.com/v4/letter/r/b38774/32.png) [@rkamath](https://forums.percona.com/u/rkamath)\ **Post date:** [July 23, 2024, 2:23pm UTC](https://forums.percona.com/t/dropcollection-potential-bug/31241/8 "2024-07-23T14:23:20Z")
I wasn’t able to test the exact delay but I’ll just try having a longer delay next time to see if that works. Thanks.