Description
While looking at the recent moss store compaction performance results with Alex Gyryk, the following issue was observed..
total 33G
rw------. 1 couchbase couchbase 13K Mar 27 11:26 data-0000000000000001.moss
rw------. 1 couchbase couchbase 25M Mar 27 11:26 data-000000000000000b.moss
rw------. 1 couchbase couchbase 1.7G Mar 27 11:28 data-000000000000001b.moss
rw------. 1 couchbase couchbase 2.1G Mar 27 11:28 data-000000000000001c.moss
rw------. 1 couchbase couchbase 2.5G Mar 27 11:29 data-000000000000001d.moss
rw------. 1 couchbase couchbase 3.0G Mar 27 11:30 data-000000000000001e.moss
rw------. 1 couchbase couchbase 3.6G Mar 27 11:30 data-000000000000001f.moss
rw------. 1 couchbase couchbase 4.2G Mar 27 11:31 data-0000000000000020.moss
rw------. 1 couchbase couchbase 5.0G Mar 27 11:32 data-0000000000000021.moss
rw------. 1 couchbase couchbase 6.0G Mar 27 11:34 data-0000000000000022.moss
There were 11 older files which were not cleaned up since the test began. The last file "22.moss" kept increasing in size and then soon enough "23.moss" was being created.
rw------. 1 couchbase couchbase 5.2G Mar 27 11:34 data-0000000000000023.moss
After 23.moss is created 22.moss continues to remain. This causes the system to quickly run out of space.
It appears that this issue is only seen when the compaction percentage is set to a non-zero value.