[
https://issues.apache.org/jira/browse/HDFS-11154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15684990#comment-15684990
]
Anu Engineer commented on HDFS-11154:
-------------------------------------
You are right it is not a proper scenario. It is a hypothetical case to
illustrate the point. However If we had locking in place, the following would
be the state table.
||First call| *Result* |*Second Call* | *Result* | *Final State* ||
|Create| Fail | Delete | Success | No Volume |
|Delete| Success| Create| Success| Volume Exists|
One great advantage with locking is that we can clearly define the end state.
The specific problem in this case is that both calls succeeding and we ending
up with no volume. That would not happen if we were to take a lock. I think
removing that ambiguity is a good thing.
> Block Storage : store server state to persistent storage
> --------------------------------------------------------
>
> Key: HDFS-11154
> URL: https://issues.apache.org/jira/browse/HDFS-11154
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: hdfs
> Reporter: Chen Liang
> Assignee: Chen Liang
> Attachments: HDFS-11154-HDFS-7240.001.patch,
> HDFS-11154-HDFS-7240.002.patch, HDFS-11154-HDFS-7240.003.patch
>
>
> Currently, all the storage state are kept in server memory. If server
> crashes, we would lose all the volume information. This JIRA stores server
> internal state into its local disk. Such that on server failure, we can
> simply restart server and restore volume information from disk.
> More specifically, the internal state written to disk is mainly the mapping
> from volume to its underlying containers, plus some meta information such as
> volume size, block size, etc.
> Note that this is only a simple, minimum set mechanism for persistence. It is
> more like a counterpart of fsimage in HDFS, but without edit logs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
