[ 
https://issues.apache.org/jira/browse/HDFS-3702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lei (Eddy) Xu updated HDFS-3702:
--------------------------------
    Attachment: HDFS-3702.006.patch

Thanks much for the quick reviews, [~andrew.wang].

bq. Can we hook into BlockPlacementPolicyDefault the same way as HDFS-4946? 

As we discussed offline, the sampling logic here is different to HDFS-4946.  In 
HDFS-4946, it tries to obtain a local node at first, if not success, it 
randomly picks from the entire DN pool. So the chosen DN is still possible to 
be local node.  However, this patch requires the chosen DN _exclusively_ from 
the rest of the DN pool.  So HDFS-4946 logic does not apply here, mostly due to 
its fallback code. 

Updated the patch to address the rest of the comments.


> Add an option for NOT writing the blocks locally if there is a datanode on 
> the same box as the client
> -----------------------------------------------------------------------------------------------------
>
>                 Key: HDFS-3702
>                 URL: https://issues.apache.org/jira/browse/HDFS-3702
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: hdfs-client
>    Affects Versions: 2.5.1
>            Reporter: Nicolas Liochon
>            Assignee: Lei (Eddy) Xu
>            Priority: Minor
>              Labels: BB2015-05-TBR
>         Attachments: HDFS-3702.000.patch, HDFS-3702.001.patch, 
> HDFS-3702.002.patch, HDFS-3702.003.patch, HDFS-3702.004.patch, 
> HDFS-3702.005.patch, HDFS-3702.006.patch
>
>
> This is useful for Write-Ahead-Logs: these files are writen for recovery 
> only, and are not read when there are no failures.
> Taking HBase as an example, these files will be read only if the process that 
> wrote them (the 'HBase regionserver') dies. This will likely come from a 
> hardware failure, hence the corresponding datanode will be dead as well. So 
> we're writing 3 replicas, but in reality only 2 of them are really useful.



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

Reply via email to