In mongodb, drop collections, but still in db.stats() ? In db.stats(), fileSize is greater, greater than storageSize I used db.coll.drop() to drop two collections in my MongoDB database. There are only system.indexes in my database now. But the output of db.stats() is:

mongos&gt; db.stats()
{
"raw" : {
    "rs0/sever01:27017,server02:27017,server03:27020" : {
        "db" : "mydb",
        "collections" : 2,
        "objects" : 1,
        "avgObjSize" : 48,
        "dataSize" : 48,
        "storageSize" : 49152,
        "numExtents" : 3,
        "indexes" : 0,
        "indexSize" : 0,
        "fileSize" : 4226809856,
        "nsSizeMB" : 16,
        "dataFileVersion" : {
            "major" : 4,
            "minor" : 5
        },
        "extentFreeList" : {
            "num" : 128,
            "totalSize" : 2680152064
        },
        "ok" : 1
    }
},
"objects" : 1,
"avgObjSize" : 48,
"dataSize" : 48,
"storageSize" : 49152,
"numExtents" : 3,
"indexes" : 0,
"indexSize" : 0,
"fileSize" : 4226809856,
"extentFreeList" : {
    "num" : 128,
    "totalSize" : 2680152064
},
"ok" : 1
}


Why is the collections number still 2? Why is fileSize is so large?

And when I run show dbs, the output shows that my database is about 4 GB.

I am not sure whether my issue is the same as the issue of dropping database here Removing Database from sharded cluster in Mongo DB.
Number of collection is equal 2:  The 2 collections are the system.indexes system.users. Execute the "show collections" command under your database to confirm.
Filesize: MongoDB allocates "physical files" or files on disk per database. For example eventsdb.0, eventsdb.1 ... Collections are stored with a distributed way within these files. Dropping a database will delete all these files and return the disk space to the OS. Dropping a collection marks the pages within the files as dead but doesn't reduce the filesize. You might have heard that as fragmentation. To reclaim disk space you need to execute the repairDatabase (http://docs.mongodb.org/manual/reference/command/repairDatabase/#dbcmd.repairDatabase) which i don't recommend because uses the global lock. Instead if you running on a 3 member replica set which is recommended, just stop one SECONDARY, delete the data directory and start the SECONDARY again. The initial sync will remove fragmentation.
Show dbs: Show dbs warps the size from filesize, so the number you see is correct.