You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jon Haddad (JIRA)" <ji...@apache.org> on 2016/11/30 23:08:58 UTC

[jira] [Created] (CASSANDRA-12979) checkAvailableDiskSpace doesn't update expectedWriteSize when reducing thread scope

Jon Haddad created CASSANDRA-12979:
--------------------------------------

             Summary: checkAvailableDiskSpace doesn't update expectedWriteSize when reducing thread scope
                 Key: CASSANDRA-12979
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-12979
             Project: Cassandra
          Issue Type: Bug
            Reporter: Jon Haddad
            Assignee: Jon Haddad


If a compaction occurs that looks like it'll take up more space than remaining disk available, the compaction manager attempts to reduce the scope of the compaction by calling {{reduceScopeForLimitedSpace()}} repeatedly.  

Unfortunately, the while loop passes the {{estimatedWriteSize}} calculated from the original call to {{hasAvailableDiskSpace}}, so the comparisons that are done will always be against the size of the original compaction, rather than the reduced scope one.

Full method below:

{code}
    protected void checkAvailableDiskSpace(long estimatedSSTables, long expectedWriteSize)
    {
        if(!cfs.isCompactionDiskSpaceCheckEnabled() && compactionType == OperationType.COMPACTION)
        {
            logger.info("Compaction space check is disabled");
            return;
        }

        while (!getDirectories().hasAvailableDiskSpace(estimatedSSTables, expectedWriteSize))
        {
            if (!reduceScopeForLimitedSpace())
                throw new RuntimeException(String.format("Not enough space for compaction, estimated sstables = %d, expected write size = %d", estimatedSSTables, expectedWriteSize));

      
        }
    }
{code}

I'm proposing to recalculate the {{estimatedSSTables}} and {{expectedWriteSize}} after each iteration of {{reduceScopeForLimitedSpace}}.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)