cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sandeep Tata (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-182) CommitLog.add doesn't really force to disk
Date Fri, 15 May 2009 18:39:45 GMT


Sandeep Tata commented on CASSANDRA-182:

FastSync (inappropriately named, IMHO) option tells the CommitLog to use a FastConcurrentWriter.
This certainly doesn't force to disk, and therefore is not an option for durable writes.

If we don't add a third option for 0.3 which forces to disk, we simply have *no* durable writes.
Even on blocking writes, it is possible that the data has not hit disk in any of the replica's

We have two options:
1. Release as is, and say "we don't offer durable writes yet"
2. Add an option to force the logs and say "this is currently a low-performing option and
will be improved for 0.4"

We can do the forces in CommitLog (probably a cleaner approach in terms of eliminating unnecessary
forces, but updateHeader writes only for CFs encountered for the first time).  The approach
in CASSANDRA-182.patch seemed minimally invasive to me :-)

Building a well-tested high-performance logger will take significantly more time. (Just testing
the logger for correctness is non-trivial.)

> CommitLog.add doesn't really force to disk
> ------------------------------------------
>                 Key: CASSANDRA-182
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>    Affects Versions: trunk, 0.3
>            Reporter: Sandeep Tata
>            Assignee: Sandeep Tata
>             Fix For: trunk, 0.3
>         Attachments: CASSANDRA-182.patch
> CommitLog.add does't really force writes to disk. This could result in acked writes being

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message