[
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)
