[SERVER-8323] Inconsistent return values from listDatabases command by mongod and mongos Created: 24/Jan/13  Updated: 25/Nov/20  Resolved: 25/Nov/20

Status: Closed
Project: Core Server
Component/s: Usability
Affects Version/s: 2.6.4
Fix Version/s: 4.9.0

Type: Bug Priority: Major - P3
Reporter: Jeremy Mikola Assignee: A. Jesse Jiryu Davis
Resolution: Done Votes: 0
Labels: ShardingRoughEdges, former-quick-wins, gm-ack, neweng
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-52544 Update IDL definition for listDatabas... Closed
Related
Backwards Compatibility: Minor Change
Operating System: ALL
Sprint: Sharding 10 (02/19/16)
Participants:

 Description   

mongos includes a totalSizeMb field in the command response, while mongod does not.

Additionally, mongod uses floating point types (casted from boost::intmax_t) for the per-database sizeOnDisk and top-level totalSize values. In contrast, mongos uses long long for its types.



 Comments   
Comment by A. Jesse Jiryu Davis [ 25/Nov/20 ]

Fixed by the changes forĀ SERVER-52544, see that ticket for the downstream implications.

Comment by Thomas Rueckstiess [ 09/Sep/14 ]

The inconsistency still exists in 2.6.4, at least the totalSizeMb field. Can't verify the type differences.

mongos

mongos> db.adminCommand({listDatabases: 1})
{
	"databases" : [
		{
			"name" : "test",
			"sizeOnDisk" : 83886080,
			"empty" : false,
			"shards" : {
				"shard0000" : 83886080
			}
		},
		{
			"name" : "config",
			"empty" : false,
			"sizeOnDisk" : 16777216
		},
		{
			"name" : "admin",
			"empty" : false,
			"sizeOnDisk" : 0
		}
	],
	"totalSize" : 83886080,
	"totalSizeMb" : 80,
	"ok" : 1
}

vs. mongod

> db.adminCommand({listDatabases: 1})
{
	"databases" : [
		{
			"name" : "local",
			"sizeOnDisk" : 83886080,
			"empty" : false
		},
		{
			"name" : "test",
			"sizeOnDisk" : 83886080,
			"empty" : false
		},
		{
			"name" : "admin",
			"sizeOnDisk" : 1,
			"empty" : true
		}
	],
	"totalSize" : 167772160,
	"ok" : 1
}

Comment by Jeremy Mikola [ 24/Jan/13 ]

Relevant commits:

Generated at Thu Feb 08 03:17:07 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.