[SERVER-13144] Size value is ignored when creating non-capped collections Created: 11/Mar/14  Updated: 10/Dec/14  Resolved: 12/Mar/14

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: 2.6.0-rc1
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Kamran K. Assignee: Eliot Horowitz (Inactive)
Resolution: Won't Fix Votes: 0
Labels: 26qa
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-14237 The "size" parameter for non-capped c... Closed
Related
is related to DOCS-3580 db.createCollection() size parameter ... Closed
is related to SERVER-8412 repairDatabase: no Cloner, and use mu... Closed
Operating System: ALL
Steps To Reproduce:

var myDB = db.getSiblingDB('repro');
myDB.dropDatabase();
myDB.createCollection('sizetest', {size: 10000000});
myDB.sizetest.stats();

Participants:

 Description   

In 2.4.9, if you specified a 'size' value for a non-capped collection, the storage space was pre-allocated. In master, the size value is no longer honored for non-capped collections. This is a regression caused by the changes from SERVER-8412.

2.4.9:

> var myDB = db.getSiblingDB('repro');
> myDB.dropDatabase();
{ "dropped" : "repro", "ok" : 1 }
> myDB.createCollection('sizetest', {size: 10000000});
{ "ok" : 1 }
> myDB.sizetest.stats();
{
	"ns" : "repro.sizetest",
	"count" : 0,
	"size" : 0,
	"storageSize" : 10002432,
	"numExtents" : 1,
	"nindexes" : 1,
	"lastExtentSize" : 10002432,
	"paddingFactor" : 1,
	"systemFlags" : 1,
	"userFlags" : 0,
	"totalIndexSize" : 8176,
	"indexSizes" : {
		"_id_" : 8176
	},
	"ok" : 1
}

master:

> var myDB = db.getSiblingDB('repro');
> myDB.dropDatabase();
{ "dropped" : "repro", "ok" : 1 }
> myDB.createCollection('sizetest', {size: 10000000});
{ "ok" : 1 }
> myDB.sizetest.stats()
{
	"ns" : "repro.sizetest",
	"count" : 0,
	"size" : 0,
	"storageSize" : 8192,
	"numExtents" : 1,
	"nindexes" : 1,
	"lastExtentSize" : 8192,
	"paddingFactor" : 1,
	"systemFlags" : 1,
	"userFlags" : 1,
	"totalIndexSize" : 8176,
	"indexSizes" : {
		"_id_" : 8176
	},
	"ok" : 1
}


Version: 575c9cbe27ba6b9ba56b810e42508d120ae44a94



 Comments   
Comment by James Tan [ 27/Mar/14 ]

The MongoDB 2.6 documentation for db.createCollection() needs to be updated/fixed - it no longer preallocates space. Prior to MongoDB 2.6.0-rc0 (e.g. 2.5.5 and before), the following commands in Mongo Shell:

use mydb
db.createCollection("somecollection", { size: 2146435072 } )

Will preallocate the following files in dbpath (e.g. /data/db):

% ls -lh mydb.*
-rw------- 1 jamestyj staff 2.0G Mar 27 15:58 mydb.0
-rw------- 1 jamestyj staff 2.0G Mar 27 15:58 mydb.1
-rw------- 1 jamestyj staff 2.0G Mar 27 15:49 mydb.2
-rw------- 1 jamestyj staff  16M Mar 27 15:58 mydb.ns

From MongoDB 2.6.0-rc0 onwards, the size option has no effect and is silently ignored, resulting in the following files:

% ls -lh mydb.*
-rw------- 1 jamestyj staff 64M Mar 27 16:05 mydb.0
-rw------- 1 jamestyj staff 16M Mar 27 16:05 mydb.ns

To mimic the original behaviour, stop mongod and run the following Bash snippet in the system terminal:

dd if=/dev/zero bs=1m count=16   of=mydb.ns
dd if=/dev/zero bs=1m count=2047 of=mydb.0
dd if=/dev/zero bs=1m count=2047 of=mydb.1
dd if=/dev/zero bs=1m count=2047 of=mydb.2
chmod 600 mydb.*

On Windows, use fsutil.exe instead of dd. For example:

fsutil.exe file createnew mydb.ns 16777216
fsutil.exe file createnew mydb.0  2146435072
fsutil.exe file createnew mydb.1  2146435072
fsutil.exe file createnew mydb.2  2146435072

Comment by Eliot Horowitz (Inactive) [ 12/Mar/14 ]

This was always accidental and not meant to be true.

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