Return-Path: X-Original-To: apmail-cassandra-commits-archive@www.apache.org Delivered-To: apmail-cassandra-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id BF4EB18291 for ; Mon, 22 Jun 2015 13:28:00 +0000 (UTC) Received: (qmail 30175 invoked by uid 500); 22 Jun 2015 13:28:00 -0000 Delivered-To: apmail-cassandra-commits-archive@cassandra.apache.org Received: (qmail 30141 invoked by uid 500); 22 Jun 2015 13:28:00 -0000 Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cassandra.apache.org Delivered-To: mailing list commits@cassandra.apache.org Received: (qmail 30130 invoked by uid 99); 22 Jun 2015 13:28:00 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 22 Jun 2015 13:28:00 +0000 Date: Mon, 22 Jun 2015 13:28:00 +0000 (UTC) From: "Joshua McKenzie (JIRA)" To: commits@cassandra.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (CASSANDRA-9627) fsync should not be "best effort" (and silently fail on e.g. windows) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/CASSANDRA-9627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14595913#comment-14595913 ] Joshua McKenzie commented on CASSANDRA-9627: -------------------------------------------- We should be good to trust NTFS for [atomicity and order preservation of operations.|https://support.microsoft.com/en-us/kb/101670]. The tl;dr: there's a transaction log for operations on NTFS that's used for recovery during a power loss that should give us the guarantees we need for that design. > fsync should not be "best effort" (and silently fail on e.g. windows) > --------------------------------------------------------------------- > > Key: CASSANDRA-9627 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9627 > Project: Cassandra > Issue Type: Bug > Components: Core > Reporter: Benedict > Priority: Blocker > Fix For: 2.2.0 rc2 > > > Currently we make an effort to synchronize both the file contents and the directory contents. Both are essential to ensure no data loss. Currently we just try to do this, and ignore the problem if we can't. Presumably this behaviour was to "sort of" support Windows (i.e. not crash). Now we officially support Windows, we need to behave better, and really IMO we should _never_ for any platform ignore a failure here. It should be part of our pre-flight checks: if we cannot do it, we cannot run safely. > It looks like this may be supported trivially through FileChannel, by opening one on the directory itself (and calling force()), although it's not clear if this will still be supported in Java 9 [see discussion here|http://mail.openjdk.java.net/pipermail/nio-dev/2015-May/003140.html]. > [~JoshuaMcKenzie]: assigning to you for now, just so it's tracked by the Windows overlord. -- This message was sent by Atlassian JIRA (v6.3.4#6332)