[
https://issues.apache.org/jira/browse/HDFS-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12732265#action_12732265
]
Sanjay Radia commented on HDFS-385:
-----------------------------------
Let me explain a little more on why I proposed the API to be experimental.
For example, the filename parameter couples the Name space layer more closely
to the block layer. This will make separating the block management out more
difficult.
FileIds (Hadoop-487) would be preferable.
The other reason for making this API experimental is the impact on HDFS
internal structure - we already find the block management code to be
very messy and are trying to figure out how to change it while keeping the NN
to be stable and reliable.
HDFS-487 (fileIds) may not get resolved in a short time.
If 487 is not settled, how can we better future proof the current 385 proposal
(but still mark it experimental)
One thought that comes to mind is changing the filename parameter to a cookie.
Initially the cookie would be implemented using the filename and later could be
changed to be the fileId.
Thoughts on this approach?
> Design a pluggable interface to place replicas of blocks in HDFS
> ----------------------------------------------------------------
>
> Key: HDFS-385
> URL: https://issues.apache.org/jira/browse/HDFS-385
> Project: Hadoop HDFS
> Issue Type: Improvement
> Reporter: dhruba borthakur
> Assignee: dhruba borthakur
> Fix For: 0.21.0
>
> Attachments: BlockPlacementPluggable.txt,
> BlockPlacementPluggable2.txt, BlockPlacementPluggable3.txt,
> BlockPlacementPluggable4.txt, BlockPlacementPluggable4.txt,
> BlockPlacementPluggable5.txt
>
>
> The current HDFS code typically places one replica on local rack, the second
> replica on remote random rack and the third replica on a random node of that
> remote rack. This algorithm is baked in the NameNode's code. It would be nice
> to make the block placement algorithm a pluggable interface. This will allow
> experimentation of different placement algorithms based on workloads,
> availability guarantees and failure models.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
