hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yi Liu (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-8863) The remiaing space check in BlockPlacementPolicyDefault is flawed
Date Tue, 11 Aug 2015 13:01:46 GMT

    [ https://issues.apache.org/jira/browse/HDFS-8863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14681766#comment-14681766
] 

Yi Liu commented on HDFS-8863:
------------------------------

{code}
final long requiredSize = blockSize * HdfsServerConstants.MIN_BLOCKS_FOR_WRITE;
final long scheduledSize = blockSize * node.getBlocksScheduled(storage.getStorageType());
final long remaining = node.getRemaining(storage.getStorageType());
if (requiredSize > remaining - scheduledSize) {
{code}
Another issue, {{getBlocksScheduled}} is for storage type, not for per storage.   So about
the {{getRemaining}}:
# sum of remaining space for storages of the storage type.  (current trunk)
# the maximum remaining space for storages of the storage type. (current patch)
# the remaining space of current storage. (As I said in previous comment)

All of them are not correct, I think we should make the {{blocksScheduled}} to track per storage
instead of storage type. Then we can choose #3 as my previous comment.

> The remiaing space check in BlockPlacementPolicyDefault is flawed
> -----------------------------------------------------------------
>
>                 Key: HDFS-8863
>                 URL: https://issues.apache.org/jira/browse/HDFS-8863
>             Project: Hadoop HDFS
>          Issue Type: Bug
>    Affects Versions: 2.6.0
>            Reporter: Kihwal Lee
>            Assignee: Kihwal Lee
>            Priority: Critical
>              Labels: 2.6.1-candidate
>         Attachments: HDFS-8863.patch
>
>
> The block placement policy calls {{DatanodeDescriptor#getRemaining(StorageType}}}} to
check whether the block is going to fit. Since the method is adding up all remaining spaces,
namenode can allocate a new block on a full node. This causes pipeline construction failure
and {{abandonBlock}}. If the cluster is nearly full, the client might hit this multiple times
and the write can fail permanently.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message