[
https://issues.apache.org/jira/browse/CASSANDRA-8126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-8126:
-----------------------------------------
Component/s: Local Write-Read Paths
> Review disk failure mode handling
> ---------------------------------
>
> Key: CASSANDRA-8126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8126
> Project: Cassandra
> Issue Type: Improvement
> Components: Local Write-Read Paths
> Reporter: Jeremy Hanna
> Priority: Minor
>
> Our disk failure modes are great in most circumstances, but there are a
> couple where they may not make sense.
> Take the example of trying to snapshot your data on a node. If permissions
> aren't set up properly, the snapshot may fail which triggers a disk failure
> which brings down the server.
> On the other hand, if you're trying to truncate a table, it may make sense to
> bring down the node if it's unable to snapshot because it's unable to
> properly make a hardlink backup of the data that's getting deleted - which is
> the expectation. This may be debatable.
> Perhaps in certain cases we can simply throw obvious errors and not bring
> down the server. In other cases, we should be clear about why we are
> bringing down the server - perhaps for specific cases like the second case,
> having a special output to indicate why it's going down. I say special
> output because it's not obvious why truncate would bring down any nodes in
> their cluster.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
