[
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)
