Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-2838

Dropping a collection does not free up disk space

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Critical - P2
    • Resolution: Works as Designed
    • Affects Version/s: 1.8.0
    • Fix Version/s: None
    • Component/s: Storage
    • Labels:
      None
    • Environment:
      linux 64-bit, ec2
    • Operating System:
      Linux

      Description

      I upgraded a mongodb server from 1.6.5 to 1.8.0, and dropped the collection after the upgrade. After dropping the collection, the disk space used on the machine was not reclaimed.

      show dbs;

      still shows the total size of the db as it was before the collection drop (~783GB).

      db.stats() shows the correct usage of the remaining collections:

      "dataSize" : 188678580624, (roughly 175 GB)

      db.stats() indicates that there are still 4 collections, even though there are only three remaining.

      > db.stats()
      {
      "db" : "xxxx",
      "collections" : 4,
      "objects" : 149504141,
      "avgObjSize" : 1262.0291275008897,
      "dataSize" : 188678580624,
      "storageSize" : 192878791072,
      "numExtents" : 127,
      "indexes" : 4,
      "indexSize" : 26608217472,
      "fileSize" : 841336487936,
      "ok" : 1
      }
      > show collections;
      p_201103
      p_201104
      system.indexes

      > db.p_201103.stats()
      {
      "ns" : "xxxx.p_201103",
      "count" : 155304251,
      "size" : 196040069044,
      "avgObjSize" : 1262.2968642629105,
      "storageSize" : 198852279456,
      "numExtents" : 127,
      "nindexes" : 2,
      "lastExtentSize" : 1991168256,
      "paddingFactor" : 1.009999999999994,
      "flags" : 1,
      "totalIndexSize" : 27651591552,
      "indexSizes" :

      { "_id_" : 6458263216, "url_1" : 21193328336 }

      ,
      "ok" : 1
      }

      > db.p_201104.stats()
      {
      "ns" : "xxxx.p_201104",
      "count" : 0,
      "size" : 0,
      "storageSize" : 8192,
      "numExtents" : 1,
      "nindexes" : 2,
      "lastExtentSize" : 8192,
      "paddingFactor" : 1,
      "flags" : 1,
      "totalIndexSize" : 16384,
      "indexSizes" :

      { "_id_" : 8192, "url_1" : 8192 }

      ,
      "ok" : 1
      }

      > db.system.indexes.stats()
      {
      "ns" : "xxxx.system.indexes",
      "count" : 4,
      "size" : 456,
      "avgObjSize" : 114,
      "storageSize" : 5120,
      "numExtents" : 1,
      "nindexes" : 0,
      "lastExtentSize" : 5120,
      "paddingFactor" : 1,
      "flags" : 0,
      "totalIndexSize" : 0,
      "indexSizes" : {

      },
      "ok" : 1
      }

      This does not show anything for the dropped collection:

      db.system.namespaces.find().toArray()
      [

      { "name" : "xxxx.system.indexes" }

      ,

      { "name" : "xxxx.p_201103" }

      ,

      { "name" : "xxxx.p_201103.$_id_" }

      ,

      { "name" : "xxxx.p_201103.$url_1" }

      ,

      { "name" : "xxxx.p_201104" }

      ,

      { "name" : "xxxx.p_201104.$_id_" }

      ,

      { "name" : "xxxx.p_201104.$url_1" }

      ]

      There do not appear to be any error messages in the log from the drop:

      Mon Mar 21 20:16:28 [conn5387] CMD: drop xxxx.p
      Mon Mar 21 20:16:29 [conn5387] query xxxx.$cmd ntoreturn:1 command:

      { drop: "p" }

      reslen:155 987ms

      The log seems normal for a few thousand lines after that (as far as I checked).

      The server has not been shut down since the upgrade to 1.8.0, and I'm also running journaling on it now since the upgrade.
      I have not changed the nssize.

        Attachments

          Activity

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: