[SERVER-22369] WT only reclaiming diskspace after 2nd compact Created: 29/Jan/16  Updated: 14/Apr/16  Resolved: 29/Jan/16

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

Type: Bug Priority: Major - P3
Reporter: Daniel Pasette (Inactive) Assignee: Keith Bostic (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-22370 compact does not run over indexes in ... Closed
Operating System: ALL
Participants:

 Description   

If I move the assert after a second call to compact, the test succeeds.

db.a.drop();
for(i=0;i<25000;i++) { db.a.insert({x:i, y:"asdfasdfasdfasdfasdfasdfasdfasdfasdf"}); }
db.adminCommand('fsync'); // force checkpoint
var collectionSize = db.a.stats().storageSize;
print("coll size: " + collectionSize);
 
print("Remove all docs...");
db.a.remove({});
db.adminCommand('fsync'); // force checkpoint
print("table size: " + db.a.stats().storageSize);
 
print("Run 1st compact...");
db.a.runCommand('compact');
db.adminCommand('fsync'); // force checkpoint
print("table size: " + db.a.stats().storageSize);
 
assert.gt(collectionSize, db.a.stats().storageSize, "collection size should be smaller after compact");



 Comments   
Comment by Daniel Pasette (Inactive) [ 01/Feb/16 ]

Not sure where/how that would be surfaced, but an info message wouldn't hurt in this case IMO. Extremely low priority.

Comment by Keith Bostic (Inactive) [ 01/Feb/16 ]

dan@10gen.com, if this was surprising enough, it's trivial to add a message "compaction ignored, file too small or insufficient blocks that could be rewritten".

Would that make things better or worse?

Comment by Keith Bostic (Inactive) [ 30/Jan/16 ]

dan@10gen.com

It was a bit strange to me that it goes ahead and does the compact if you ask it nicely the second time though.

That was confusing – it turns out the compact does nothing, both times.

The WT blockmanager code does first-fit block allocation when writing checkpoints, so that when new checkpoints are written, the tail of the file can be truncated. I verified both compactions fail, so that's what I think is happening here.

Comment by Daniel Pasette (Inactive) [ 30/Jan/16 ]

I wasn't aware of that behavior but that seems quite reasonable. It was a bit strange to me that it goes ahead and does the compact if you ask it nicely the second time though. Leaving this as WAD.

Comment by Keith Bostic (Inactive) [ 29/Jan/16 ]

dan@10gen.com, what's happening here is the file size never gets over 1MB, and WiredTiger compaction ignores files under a MB in size.

I'll close this one "works as designed" for now; let's talk if we shouldn't be limiting compaction this way.

Generated at Thu Feb 08 04:00:12 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.