Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Kafka >> mail # dev >> [jira] [Commented] (KAFKA-615) Avoid fsync on log segment roll

Copy link to this message
[jira] [Commented] (KAFKA-615) Avoid fsync on log segment roll

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

Jay Kreps commented on KAFKA-615:

1.1 Good catch
2.1 My desire is to ensure that checkpoints are flushed prior to taking new writes.
3.1 TestLogPerformance is deleted in this patch. Previously TestLogPerformance tested the log and LinearWriteTest tested writing to files. But as I did the latency testing LinearWriteTest got better and better. Finally I just added the log testing into that tool. I deleted it as part of this patch because it was a subset of the functionality in LinearWriteTest.
3.2 In all our tests we test with the filesystem, mount options, and configuration you have. I think trying to control OS-specific thing from the tool is overkill.
> Avoid fsync on log segment roll
> -------------------------------
>                 Key: KAFKA-615
>                 URL: https://issues.apache.org/jira/browse/KAFKA-615
>             Project: Kafka
>          Issue Type: Bug
>            Reporter: Jay Kreps
>            Assignee: Neha Narkhede
>         Attachments: KAFKA-615-v1.patch, KAFKA-615-v2.patch, KAFKA-615-v3.patch, KAFKA-615-v4.patch, KAFKA-615-v5.patch, KAFKA-615-v6.patch
> It still isn't feasible to run without an application level fsync policy. This is a problem as fsync locks the file and tuning such a policy so that the flushes aren't so frequent that seeks reduce throughput, yet not so infrequent that the fsync is writing so much data that there is a noticable jump in latency is very challenging.
> The remaining problem is the way that log recovery works. Our current policy is that if a clean shutdown occurs we do no recovery. If an unclean shutdown occurs we recovery the last segment of all logs. To make this correct we need to ensure that each segment is fsync'd before we create a new segment. Hence the fsync during roll.
> Obviously if the fsync during roll is the only time fsync occurs then it will potentially write out the entire segment which for a 1GB segment at 50mb/sec might take many seconds. The goal of this JIRA is to eliminate this and make it possible to run with no application-level fsyncs at all, depending entirely on replication and background writeback for durability.

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