mongoDB : Restoring space after db.repairDatabase
I am bit confused about the size before and after the repairDatabase. I was thinking space should get release. I haven't tried compact option


In general you should consider the  repairDatabase  command a last resort to be used when you actually need to salvage or repair a database and don't have a better data source to copy from (eg. a copy of the data from another replica set member of backup). Historically the repair command was often (ab)used to forcibly rebuild databases using the older MMAP storage engine, but this is no longer recommended practice. The repair operation obtains a global write lock and will block all other operations on your MongoDB server until complete.

With MongoDB 3.2.3+ using WiredTiger (the default storage engine), you can use the compact command to release unused disk space to the operating system for a specific collection. Typically this isn't required unless you find space is not being reused effectively over time. 

NOTE: while compacting a collection other operations on the same database will be blocked so this is an activity you would only want to perform during scheduled maintainance periods. Depending on the layout of data on disk, compaction may also not result in significant storage space savings. A better operational approach to reclaim all unused space while avoiding downtime would be to resync a mongod as a member of a replica set.

A few points that should help clarify your observations on size numbers with WiredTiger:


Data in WiredTiger is compressed by default and the representation on disk is different from the representation in memory.
There are several potentially interesting measures of size including data size, storageSize, totalIndexSize, and totalSize (which adds storageSize + totalIndexSize). You can inspect these metrics (and more) via db.collection.stats().
Data written to files on disk is grouped into block allocations (in multiples of 4KB) which is why your single document insertion resulted in a 4KB storageSize and 8KB totalSize (the extra 4KB is the initial allocation for the _id index file). Block allocations are variable sized and managed by the WiredTiger storage engine.
The WiredTiger storage engine does not perform in-place updates on data; it uses an MVCC (MultiVersion Concurrency Control) approach with Snapshots and Checkpoints. This can lead to some apparently contradictory observations where storage space may need to grow to accommodate multiple document versions even though the data size is not increasing. Allocations from older document versions will be marked available for reuse as checkpoints complete, and WiredTiger will try to minimize storage fragmentation with a best-fit allocation from existing storage where possible.



  If I observe the numbers produced after above operations, I was under assumption that size should go back to empty, though show dbs shows mc as 0.000GB.



The show dbs command indicates the actual data size (eg. db.mc.stats().size), which may be much larger than the storageSize (due to compression) or smaller than storageSize (due to preallocated/unused space). Your example is the latter: there is storage space available for reuse.
When you deleted documents you used db.collection.remove({}). This syntax deletes matching documents without removing collection metadata (eg. index definitions) or compacting storage space. If you want to more immediately drop an entire collection and free storage space you should instead use db.collection.drop().


For more information, see:


WiredTiger Storage Engine in the MongoDB documentation
A Technical Introduction to WiredTiger presentation from MongoDB World 2015.