[
https://issues.apache.org/jira/browse/HDFS-13248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16812545#comment-16812545
]
Íñigo Goiri commented on HDFS-13248:
------------------------------------
Thanks [~hexiaoqiao] for clarifying the {{ClientProtocol}} scope.
It makes sense to just use the new one between the Router and the Namenode.
However, I'm not a fan of duplicating methods and having extra signatures for
similar things.
My vote is for modifying the IPC/RPC layer to add the extra clientHostname
field.
The auditing that [~ayushtkn] mentioned is also a plus.
The concerns regarding this approach are:
* Fake client hostname: I don't quite get this one.
* Security vulnerabilities: I think this should be fine.
* Common core IPC layer protocol changes: I think we can handle this.
> RBF: Namenode need to choose block location for the client
> ----------------------------------------------------------
>
> Key: HDFS-13248
> URL: https://issues.apache.org/jira/browse/HDFS-13248
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Reporter: Weiwei Wu
> Assignee: Íñigo Goiri
> Priority: Major
> Attachments: HDFS-13248.000.patch, HDFS-13248.001.patch,
> HDFS-13248.002.patch, HDFS-13248.003.patch, HDFS-13248.004.patch,
> HDFS-13248.005.patch, HDFS-Router-Data-Locality.odt, RBF Data Locality
> Design.pdf, clientMachine-call-path.jpeg, debug-info-1.jpeg, debug-info-2.jpeg
>
>
> When execute a put operation via router, the NameNode will choose block
> location for the router, not for the real client. This will affect the file's
> locality.
> I think on both NameNode and Router, we should add a new addBlock method, or
> add a parameter for the current addBlock method, to pass the real client
> information.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
