[ 
https://issues.apache.org/jira/browse/CASSANDRA-9568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Ellis resolved CASSANDRA-9568.
---------------------------------------
       Resolution: Invalid
    Reproduced In: 2.2.0 rc1, 2.1.6, 2.0.16  (was: 2.1.6, 2.0.16, 2.2.0 rc1)

The commitlog allocates its storage in files called "segments," which are 
created with a constant size and "filled up" as writes come in.  This has the 
dual benefit of avoiding fragmentation on spinning disks and allowing us to use 
the less expensive fdatasync when writing updates, as opposed to full fsync 
which has to journal the new file length as well.

> commit_sync: batch either doesn't work or has confusing documentation
> ---------------------------------------------------------------------
>
>                 Key: CASSANDRA-9568
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9568
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Jim Witschey
>
> Based on the language 
> [here|http://docs.datastax.com/en/cassandra/2.1/cassandra/configuration/configCassandra_yaml_r.html?scroll=reference_ds_qfg_n1r_1k__commitlog_sync],
>  I thought that when {{commitlog_sync}} was set to {{batch}}, inserts would 
> block until the commitlog was written to and fsynced. As the docs say,
> {quote}
> When using this method, writes are not acknowledged until fsynced to disk.
> {quote}
> This doesn't seem to be the case. I've pushed a failing dtest 
> [here|https://github.com/riptano/cassandra-dtest/compare/master...mambocab:commitlog_sync-batch-bug]
>  demonstrating the behavior; even after writing thousands of rows, the size 
> of the commitlog doesn't change. I see similar values when measuring the 
> commitlog size via JMX, so I don't believe it's a measurement error on my 
> part. I see this behavior on trunk and on HEAD for 2.2, 2.1, and 2.0.
> This should either be fixed, or the behavior should be more clearly 
> documented. I asked about the intended behavior in #cassandra and didn't get 
> an answer.



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

Reply via email to