[
https://issues.apache.org/jira/browse/HDFS-15195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17046826#comment-17046826
]
Ayush Saxena commented on HDFS-15195:
-------------------------------------
Do you tend to change the BlockPool of the block to move the data to another
namenode?
If so? It isn't that simple as just moving the block data from one directory to
another in the namenode. for the other namenode to recognize, The metadata
needs to present too at the namenode.
HDFS-2139 had some interesting stuff, It used hard links to move blocks in same
datanode. May be you can give a check.
If you tend to have some design work done, do share the design document
> In place namenode fedaration
> ----------------------------
>
> Key: HDFS-15195
> URL: https://issues.apache.org/jira/browse/HDFS-15195
> Project: Hadoop HDFS
> Issue Type: New Feature
> Reporter: Amithsha
> Priority: Major
>
> In the current scenario federating the existing data is not possible. This
> impacts the implementation of HDFS federation on the production cluster with
> more than PB of data. Because we need to copy the data from the old set of
> namenodes to the new set of namenodes. From the data node directory structure
> its clear that if we move the blocks of particular data from namenode_set_1
> dir (dfs/data/current/BP-xxx) to namenode_set_2 dir (dfs/data/current/BP-yyy)
> will solve the issue. Why can’t we make this us a new future where it will
> ask for dir to get federated and stop the write process until move completes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
