Optimize taking two steps and extra disk space

[Shawn Heisey]

I've noticed something odd in Solr 3.2 when it does an optimize.  One of 
my shards (freshly built via DIH full-import) had 37 segments, totalling 
17.38GB of disk space.  13 of those segments were results of merges 
during initial import, the other 24 were untouched after creation.  
Starting at _0, the final segment before optimizing is _co.  The 
mergefactor on the index is 35, chosen because it makes merged segments 
line up nicely on "z" boundaries.

The optmization process created a _cp segment of 14.4GB, followed by a 
_cq segment at the final 17.27GB size, so at the peak, it took 49GB of 
disk space to hold the index.

Is there any way to make it do the optimize in one pass?  Is there a 
compelling reason why it does it this way?

Thanks,
Shawn