[SERVER-8435] figure out 2.4 quantized record size upgrade path when using uniform size documents Created: 01/Feb/13 Updated: 11/Jul/16 Resolved: 16/Feb/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | 2.4.0-rc1 |
| Type: | Question | Priority: | Major - P3 |
| Reporter: | Aaron Staple | Assignee: | Eliot Horowitz (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Participants: | |||||
| Description |
|
If all documents are the same size, reuse of free space has historically been straightforward. When a new document is inserted, it can use the space of a previously deleted record of the same size. The addition of quantized size record allocation in 2.4 means that records allocated after upgrading to 2.4 will typically be a bit larger than records allocated pre 2.4 (they will be larger unless the sizes pre 2.4 were already of a quantized size). For users with uniform size documents, the increase in the required record size means that the deleted space for any documents that existed prior to the 2.4 upgrade will be orphaned forever after upgrading to 2.4, potentially (also) causing increased fragmentation. Here are some simple tests to demonstrate this. The first, insert.js, inserts uniform size documents. The second, replace.js, replaces the uniform size documents with other uniform size documents, of the same bson size. insert.js
replace.js
Here the results of running the tests, first both on master, then both on 2.2, then inserting with 2.2 and replacing with master. 1) 2) 3) |
| Comments |
| Comment by auto [ 16/Feb/13 ] |
|
Author: {u'date': u'2013-02-16T02:26:34Z', u'name': u'Eric Milkie', u'email': u'milkie@10gen.com'}Message: |
| Comment by Eric Milkie [ 16/Feb/13 ] |
|
Some unit tests are failing, like geo_center_sphere2.js. |
| Comment by auto [ 15/Feb/13 ] |
|
Author: {u'date': u'2013-02-15T19:39:58Z', u'name': u'Eliot Horowitz', u'email': u'eliot@10gen.com'}Message: |