[SERVER-536] Drop collection, restart mongod, create index results in unnecessary creation of data files Created: 13/Jan/10  Updated: 29/May/12  Resolved: 19/Jan/10

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 1.3.0
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Yun Huang Yong Assignee: Aaron Staple
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux 64 bit (Ubuntu)


Attachments: Text File mongod.log    
Participants:

 Description   

Reproduction steps:

(using the default 'test' database)
1. db.dropDatabase() – ensure no data files already present for 'test'
2. db.test.ensureIndex(

{j:1}

)
3. db.test.drop()
4. ls -l mongo data dir and observe that test.0 and test.1 are present (and on subsequent iterations test.2, test.3 etc)
5. restart mongod
6. goto 2.

Each iteration creates an additional test.X datafile even though no data is stored. Curiously without the restart of mongod the drop & ensureIndex behave as expected and no additional data files are created.

I have observed this behaviour with 1.3 release and the 2010-01-13 1.3 nightly.

1.2.1 appears to be ok, only .0 and .1 files are created.



 Comments   
Comment by Yun Huang Yong [ 19/Jan/10 ]

Compiled from master head just now to confirm this problem is resolved.

thanks!
yun

Comment by Aaron Staple [ 19/Jan/10 ]

I believe this is a duplicate of SERVER-493, which was just fixed. Please give tonight's nightly a try if you like.

Comment by Yun Huang Yong [ 19/Jan/10 ]

This was with a clean dbpath.

For the above log I downloaded mongodb-linux-x86_64-1.3.0 fresh, unpacked into a clean dir and used its own dbpath (../data relative to the bin/ dir).

Just to add more info - the extra data files are created as a result of the ensureIndex call. So the key is that the collection is dropped /before/ mongod is restarted, and the ensureIndex is /after/ the restart.

Comment by Yun Huang Yong [ 19/Jan/10 ]

mongod with -vvvvv

Comment by Aaron Staple [ 19/Jan/10 ]

Hi Yun,

I was unable to reproduce this behavior using the 1.3.0 release on a 64bit ubuntu instance. (Only the .0 and .1 files were created in my testing.)

Would it be possible for you to run mongod with the -v option to provide extra debug info and send a log of your runs? Also, when you started your test, was there some data in the dbpath or was it a clean dbpath? I am just trying to duplicate the conditions under which this failure occurred.

Generated at Thu Feb 08 02:54:25 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.