[
https://issues.apache.org/jira/browse/HDFS-15087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17036004#comment-17036004
]
Xiaoqiao He commented on HDFS-15087:
------------------------------------
Thanks [~LiJinglun] for your proposal, it is very interesting and useful
feature in my opinion. Some minor concern from me,
1. For step saveTree, it generates 2 files, TREE-FILE and TREE-META
respectively, I don't get the difference with one meta file with all
information. My concerns is we should skip to check consistency and other
sanity checks if keep only one meta file.
2. It may be not enough to ensure source directory not changes if only revoke
write permission for source directory/file since some super user action
actually not do permission check when do read/write ops. +1 for adding extra
xattributes to refuse write operation request.
{quote}remove all permissions of the source directory and force
recoverLease()/close all open files. Normal users can't change the source
directory anymore, both directories and files.{quote}
3. Any consideration about HA mode? do we need to distribution meta file/files
to both ANN and SBN before execute GraftTree or both of them request meta data
from external storage? AND how do we undo it if ANN Graft part of inode tree
then ha failover due to some reasons? otherwise it would be not strong
consistent between ANN and SBN in my opinion.
4. Some user case s do not shared DN's in federated clusters as [~ayushtkn]
mentioned above, it needs to rollback to block transfer if use hard-link
solution?
5. It introduces {{Scheduler}} and {{Externel Storage}} modules in design doc,
what about use Router to schedule rename task and NN local storage (may be it
is same as fsimage persist path) to keep meta data then we could not need
extra module and reduce maintain cost.
Thanks again [~LiJinglun], I do not review the initial patch carefully, please
correct me if I missing something.
About FastCp, we use it since 3 years ago, and it is not obvious different with
DistCp except effective because hardlink(FastCp) vs transfer(DistCp) in my
opinion. If anyone is interested for FastCp as one option for this solution, I
would like to push it forward again.
> RBF: Balance/Rename across federation namespaces
> ------------------------------------------------
>
> Key: HDFS-15087
> URL: https://issues.apache.org/jira/browse/HDFS-15087
> Project: Hadoop HDFS
> Issue Type: Improvement
> Reporter: Jinglun
> Priority: Major
> Attachments: HDFS-15087.initial.patch, HFR_Rename Across Federation
> Namespaces.pdf
>
>
> The Xiaomi storage team has developed a new feature called HFR(HDFS
> Federation Rename) that enables us to do balance/rename across federation
> namespaces. The idea is to first move the meta to the dst NameNode and then
> link all the replicas. It has been working in our largest production cluster
> for 2 months. We use it to balance the namespaces. It turns out HFR is fast
> and flexible. The detail could be found in the design doc.
> Looking forward to a lively discussion.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
