[
https://issues.apache.org/jira/browse/HDFS-7354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14382400#comment-14382400
]
Zhe Zhang commented on HDFS-7354:
---------------------------------
Thanks Nicholas for the suggestion.
Under HDFS-7369 I [proposed |
https://issues.apache.org/jira/browse/HDFS-7369?focusedCommentId=14318849&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14318849]
a first order approximation to estimate the risk level of striped blocks:
# A block group with _m_ data blocks and _k_ parity blocks is equivalent to a
contiguous block with replication factor _k+1_, because both can tolerate _k_
failures
#If _n_ blocks are healthy among the _m+k_ blocks, it's equivalent to having
_n-m+1_ healthy replicas, calculated from _(k+1) - ((m+k) - n)_, or
_replicationFactor - numLostReplicas_.
I believe [~jingzhao] is working on a patch to detect at-risk striped blocks
and add them to {{UnderReplicatedBlocks}}. This JIRA aims to further
differentiate parity blocks. Assuming a block group has lost 1 block. If that
missing block is parity data, the priority should be even lower than missing a
raw data block, because client will suffer from longer latency if a raw data
block is missing.
> Support parity blocks in block management
> -----------------------------------------
>
> Key: HDFS-7354
> URL: https://issues.apache.org/jira/browse/HDFS-7354
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Reporter: Zhe Zhang
> Assignee: Zhe Zhang
>
> Parity blocks are not accessed during normal I/O operations. They should
> therefore be treated with lower priority in the block recovery framework.
> This JIRA tracks this effort as well as other special treatments which might
> be needed for parity blocks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
