[
https://issues.apache.org/jira/browse/HDFS-13208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16382519#comment-16382519
]
Wei Yan commented on HDFS-13208:
--------------------------------
Ok, finally I got through the pipeline. In short, it can be resolved by
HDFS-13212.
So when in step 2, we "rm" a mount point, and then issue a "ls" cmd. It will
leave a record in the local cache. After step 3, although the mount point
changed, the cache still refers to default NS, so a follow-up "ls" will still
point to the wrong location (the cached one after step 2).
This cannot be reproduced in [~linyiqun] 's testcase, as it doesn't involve
local cache operation (which needs to run FileSystem.listStatus()).
Closing this ticket as a duplicate.
> RBF: Mount path not available after ADD-REMOVE-ADD
> --------------------------------------------------
>
> Key: HDFS-13208
> URL: https://issues.apache.org/jira/browse/HDFS-13208
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Reporter: Wei Yan
> Assignee: Wei Yan
> Priority: Critical
>
> To reproduce this issue, run the following commands at Router 1:
> {code:java}
> $ hdfs dfsrouteradmin -add /test1 ns1 /ns1/test1
> $ hdfs dfsrouteradmin -rm /test1
> $ hdfs dfsrouteradmin -add /test1 ns1 /ns1/test1{code}
> "hdfs dfs -ls hdfs://Router1:8020/test1" works well after step 1. After step
> 3 when we add /test1 back, Router 1 still returns "No such file or
> directory".
> But after step 3, when we run cmd "hdfs dfs -ls hdfs://Router2:8020/test1"
> talking to another Router, it works well.
> From Router logs, I can see StateStoreZookeeperImpl and MountTableResolver
> are updated correctly and in time. Not find the root case yet, still looking
> into it.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
