0

I'm not sure if this has already been asked but I'm facing a weird issue in MongoDB 4.2.8(Standalone).

We have a single collection running which uses a TTL index to delete all documents that are older than 24 hours.

Now the weird issue - df -h shows the our external mongod volume as 94GB used, however du -hsx shows that the data is only 85GB and logs are 0KB.

Why is there a discrepancy of around 9GB on the disk? I read that db.compact could release free space to the OS but we need to be 100% sure there will be zero downtime with the operation.

Could anyone guide us on how to release the space with no downtime?

EDIT -

I just ran db.stats() in my MongoDB instance this is the output -

"objects" : 74749716,
"avgObjSize" : 3462.7832923539136,
"dataSize" : 258842067673,
"storageSize" : 85391945728,
"numExtents" : 0,
"indexes" : 13,
"indexSize" : 3864145920,
"scaleFactor" : 1,
"fsUsedSize" : 100955877376,
"fsTotalSize" : 107346903040,
"ok" : 1

The question being how is storageSize and fsUsedSize different?

0

As your two space readings both come from the OS environment (neither df nor du inspect the contents inside your database files) this is an OS/filesystem matter not a MongoDB one, so https://superuser.com/ or https://serverfault.com/ would be better places to search for an answer (do search first rather than just asking, this is likely to be a common issue so most likely will have been asked and answered multiple times).

A quick summary of some possible factors resulting in the discrepancy include:

  1. Linux native filesystems (ext2, ext3, ext4) usually default to reserve some space for the root user to aid clean-up when things become full or near full and as a small anti-fragmentation measure. This default is often 5% which on large volumes can be a lot of space. See here amongst other references for more information including how to alter this reservation.
  2. du might not be hidden “.” files.
  3. Are you running du at the root of the filesystem? If not there may be files above that it is not counting (df always reflects the whole filesystem).
  4. If there are mount points within this filesystem, there could be files hidden by the mount that are not being counted by du.
2
  • I actually have gone through a few answers but they were generally related to replica sets rather than a standalone server. One suggestion was also about a previous mount underneath the current mount point but that was empty. 1. I'm using XFS and there was no reserved space when I created the volume. 2. I did consider that as well however ll -a and du -hsx .[^.]* didn't find any hidden folders. 3. I'm running du -hsx at the mount point for the external volume. 4. Already checked for hidden files. Could you advise whether compact would require downtime? Aug 13 at 10:25
  • I don't know ab out downtime but I expect that compact will make no difference anyway because the discrepancy you have described between what is reported by df and du seems to be either in the filesystem or how those tools are reading it, not the database file contents. If Mondo uses sparse files then du's --apparent-size option may be useful and give different results. Other than that, try asking on SU or SF. Aug 13 at 11:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.