Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Wed, 29 Feb 2012 09:37:57 +0000 (UTC)
From: "Peter Schuller (Commented) (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: 
 <1610241439.1928.1330508277082.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1829820033.7972.1329967315902.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (CASSANDRA-3950) support trickling fsync() on
 writes
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Peter Schuller commented on CASSANDRA-3950:
-------------------------------------------

I'm fine with that. I intentionally kept it even for simplicity, but on second though it's actually a good idea to keep it nicely aligned (aligning with SSD page size is good, and an even MB is very likely to be).
                
> support trickling fsync() on writes
> -----------------------------------
>
>                 Key: CASSANDRA-3950
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-3950
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Peter Schuller
>            Assignee: Peter Schuller
>             Fix For: 1.1.0
>
>         Attachments: CASSANDRA-3950-1.1-v2.txt, CASSANDRA-3950-1.1-v3.txt, CASSANDRA-3950-1.1.txt
>
>
> Attaching a patch to support fsync():ing every N megabytes of data written using sequential writers. The motivation is to avoid the kernel flushing out pages in bulk.
> It makes sense for both platters and SSD:s, but it's particularly good for SSD:s because the negative consequences of fsync():ing more often are much more limited than with platters, and the *need* is to some extent greater because of the fact that with SSD:s you're much more likely to be e.g. streaming data quickly or compacting quickly, since you're not having to throttle everything as extremely as with platters, and you easily write fast enough for this to be a problem if you're targetting good latency at the outliers.
> I'm nominating it for 1.1.0 because, if disabled, the probability of this being a regression seems very low.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira