SERVER-3791 compact now restarts the extent sizing algorithm

The 'compact' operation sequentially copies all the records in the namespace into a new extent. Since this operation creates no new data,
the standard extent logarithmic sizing should not apply; the algorithm is only to accomodate data growth.
Instead, we will start back at the beginning with the smallest extent size.  This will allow for freed-extent reuse over multiple compacts.
Note that the only way to have freed extents in a database is to run compact, so the first time you run it, there will always be new extents created.
Subsequent compacts will potentially reuse the freed extents.

The compact speed unit test's time comparison seemed backwards to me, so I fixed it and made it a real assert.
I also bumped up the padding in the padding test so that it would trigger a new extent and thus have a material increase in the storage size.

1 files changed, 1 insertions, 1 deletions

diff --git a/jstests/compact.js b/jstests/compact.js
index 8a0591ae009..cbeb0736582 100644
--- a/jstests/compact.js
+++ b/jstests/compact.js
@@ -27,7 +27,7 @@ assert(t.getIndexes().length == 2);
 var ssize = t.stats().storageSize;
 
 print("2");
-res = db.runCommand({ compact: 'compacttest', dev: true,paddingBytes:100 });
+res = db.runCommand({ compact: 'compacttest', dev: true,paddingBytes:1000 });
 assert(res.ok);
 assert(t.count() == 9);
 var v = t.validate(true);