cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Resolved] (CASSANDRA-9568) commit_sync: batch either doesn't work or has confusing documentation
Date Tue, 09 Jun 2015 03:50:00 GMT


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:
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Jim Witschey
> Based on the language [here|],
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|]
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

View raw message