[
https://issues.apache.org/jira/browse/HDFS-3702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15204981#comment-15204981
]
stack commented on HDFS-3702:
-----------------------------
[~arpiagariu] You'd like to purge all of the CreateFlag parameters Arpit?
CreateFlag seems to be how other filesystems do color on a particular creation
and this patch was able to make use of it and save changing a bunch of method
signatures. Seems kinda useful? And seems like we could get more flags on
CreateFlag down the road (ASYNC?).
bq. What do you think of per-target block placement policies as proposed in
this comment e.g. set a custom placement policy for /hbase/.logs/.
Seems like a grand idea (then and now) being able to do it for a whole class of
files based-off their location in HDFS. Would this be instead of this patches'
decoration on CreateFlag? I'd suggest not. I like this patch. It gets us what
we want nicely. No need for an admin operator to remember to set attributes on
specific dirs (99% won't); we can just do the code change in hbase (and rip out
the hacks we have had in place for years now that have been our workaround in
the absence of this patch).
Thanks
> 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, HDFS-3702.007.patch,
> HDFS-3702.008.patch, HDFS-3702_Design.pdf
>
>
> 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)
