You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jonathan Ellis (JIRA)" <ji...@apache.org> on 2013/06/26 16:30:21 UTC

[jira] [Commented] (CASSANDRA-5704) Truncate flushes to disk again in 1.2, even with durable_writes=false

    [ https://issues.apache.org/jira/browse/CASSANDRA-5704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13693995#comment-13693995 ] 

Jonathan Ellis commented on CASSANDRA-5704:
-------------------------------------------

Hmm.  I'm not sure I'm convinced that we should not save the truncation record when durable writes are disabled.  Durable writes means "I'm okay if you lose the data I'm about to write in case of power failure," but not flushing the truncate means "Data that was supposed to be gone, could reappear" which feels semantically different to me.

WDYT [~brandon.williams] [~tjake]?

(I note that for production use, CASSANDRA-4906 made the biggest difference since now we only need to flush the table being truncated instead of everyone.)
                
> Truncate flushes to disk again in 1.2, even with durable_writes=false
> ---------------------------------------------------------------------
>
>                 Key: CASSANDRA-5704
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5704
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.2.5
>            Reporter: Christian Spriegel
>            Assignee: Christian Spriegel
>            Priority: Minor
>             Fix For: 1.2.7
>
>         Attachments: CASSANDRA_5704_V1_1_2.patch, CASSANDRA_5704_V1_trunk.patch
>
>
> I just upgraded my dev-environment to C* 1.2. Unfortunetaly 1.2 makes my JUnit tests slow again, due to a blocking-flush in saveTruncationRecord().
> With Cassandra 1.1 truncate was very fast due to: CASSANDRA-4153
> My proposal is to make saveTruncationRecord() only flush when durableWrites are enabled.
> My assumption is that if somebody turn off durable writes then he does not mind if truncate is not guaranteed to be durable either.
> I successfully tested the following patch with my testsuite. Its as fast as it was with 1.1 (maybe even faster!):
> {code}
> @@ -186,5 +186,8 @@ public class SystemTable
>          String req = "UPDATE system.%s SET truncated_at = truncated_at + %s WHERE key = '%s'";
>          processInternal(String.format(req, LOCAL_CF, truncationAsMapEntry(cfs, truncatedAt, position), LOCAL_KEY));
> -        forceBlockingFlush(LOCAL_CF);
> +        
> +        KSMetaData ksm = Schema.instance.getKSMetaData(cfs.table.name);
> +        if (ksm.durableWrites) // flush only when durable_writes are enabled
> +            forceBlockingFlush(LOCAL_CF);
>      }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira