You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Aleksey Yeschenko (JIRA)" <ji...@apache.org> on 2015/11/11 18:19:12 UTC

[jira] [Updated] (CASSANDRA-8126) Review disk failure mode handling

     [ https://issues.apache.org/jira/browse/CASSANDRA-8126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aleksey Yeschenko updated CASSANDRA-8126:
-----------------------------------------
    Priority: Minor  (was: Major)

> Review disk failure mode handling
> ---------------------------------
>
>                 Key: CASSANDRA-8126
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8126
>             Project: Cassandra
>          Issue Type: Improvement
>            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)