[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: |
|
| Participants: |
| Description |
|
Reproduction steps: (using the default 'test' database) ) 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! |
| Comment by Aaron Staple [ 19/Jan/10 ] |
|
I believe this is a duplicate of |
| 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. |