hfutatzhanghb commented on code in PR #5262:
URL: https://github.com/apache/hadoop/pull/5262#discussion_r1060434510
##########
hadoop-hdfs-project/hadoop-hdfs-rbf/src/main/java/org/apache/hadoop/hdfs/server/federation/router/RouterRpcServer.java:
##########
@@ -687,7 +687,7 @@ <T> T invokeAtAvailableNs(RemoteMethod method, Class<T>
clazz)
// If default Ns is present return result from that namespace.
if (!nsId.isEmpty()) {
try {
- return rpcClient.invokeSingle(nsId, method, clazz);
+ return rpcClient.invokeSingle(nsId, method, clazz, "");
Review Comment:
> > Yes，the src is not the dst path, but we can use the src to lookup real
dst path in mount table. Here, we can not execute
this.subclusterResolver.getMountPoints(path);, because the statement is
time-consuming.
>
> From correctness point of view it isn't correct. If `/mount/path` points
to Ns0 `/dir` and we log` /mount/path` in the namenode, it can lead to
confusions if the namenode also has a path named `/mount/path`, If you operate
on `/dir` via router `/mount/path` and if you directly operate on `/mount/path`
on the namenode.
>
> If it has serious performance penalties we need to make it configurable
and then figure out what can be done when the config is disabled.
Hi, @ayushtkn , can we prepend some specific prefix, such as "RBF#src_path:"
to the dir? In this way, we can distinguish RBF scene from direct namenode
scene. What’s your opinion? I am looking forward to your reply and do the next
steps. thanks again~
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
