Atualização (março de 2015): A partir da versão 3.0, existem vários mecanismos de armazenamento disponíveis no MongoDB. Esta resposta se aplica ao mecanismo de armazenamento MMAP (ainda o padrão no MongoDB 3.0), a resposta para outros mecanismos (WiredTiger, por exemplo) é bem diferente e pode ser ajustável e ajustável. Portanto, se você estiver usando outro mecanismo, leia os documentos relevantes para esse mecanismo de armazenamento para determinar quais são os padrões e opções de reutilização de espaço.

Com o mecanismo de armazenamento MMAP, quando os documentos são excluídos, o espaço deixado para trás é colocado em uma lista livre. No entanto, para usar o espaço, será necessário inserir documentos de tamanho semelhante posteriormente, e o MongoDB precisará encontrar um espaço apropriado para esse documento dentro de um determinado período de tempo (uma vez que o tempo limite de olhar para a lista, ele apenas anexará) caso contrário a reutilização do espaço não vai acontecer com muita frequência. Essa exclusão é feita nos arquivos de dados, portanto, não há recuperação de espaço em disco acontecendo aqui - tudo isso é feito internamente nos arquivos de dados existentes.

Se você posteriormente fizer um reparo ou ressincronizar um secundário do zero, os arquivos de dados serão regravados e o espaço em disco será recuperado (qualquer preenchimento nos documentos também será removido). É aqui que você verá a recuperação de espaço real no disco. Para quaisquer outras ações (compacto incluído), o uso do disco não será alterado e poderá até aumentar.

Com o 2.2+, agora você pode usar o comando collMod e a opção usePowersOf2Sizes para tornar mais provável a reutilização do espaço excluído (observe que esse é o padrão no 2.6+). Isso significa que a alocação de espaço inicial para um documento é um pouco menos eficiente (512 bytes para um documento de 400 bytes, por exemplo), mas significa que, quando um novo documento é inserido, é mais provável que seja possível reutilizar esse espaço. Se você estiver excluindo (ou aumentando e, portanto, movendo) documentos muito, isso será mais eficiente a longo prazo.

Para quem estiver interessado, uma das pessoas que escreveu muito código de armazenamento (Mathias Stearn) tem uma ótima apresentação sobre o armazenamento interno, que pode ser encontrada aqui