04-21-2017 02:46 PM
@Yongjun Zhang Can you please reply to my last comment regarding using the diff only with full listing in case of failures.
04-21-2017 02:54 PM
04-21-2017 08:44 PM
Thanks for the clarification. Sorry I missed this reply earlier. Good to know that it's not resulted from distcp. So there is no snapshot opertaion failure message even if it failed?
04-21-2017 09:22 PM
@Yongjun Zhang you last suggestion to issue distcp after the diff failure is making our life more complex since i need to delete 4 snapshots, create new s0 snapshot , issue distcp and then create s0 at destination.
I still wondering why the full listing in case of failures was disabled in the new version.
04-21-2017 09:40 PM
04-21-2017 09:52 PM
In both case if user passes -delete or not in the reqular distcp after the fallback, the -diff in the next run will correct the situation.
Yes, in case of snapshot error, we are getting the network issue message like connection timeout between node xxx and namenodexx:8020, to manage different errors to each snapshot in one cron is adding more compexity to the snapshot cycle management.
More important, such changes that is not backward compaitible should be communicated or mentioned in the release notes or in the rdiff documntation, imagine that i want to upgrade my cluster, and after the upgrade either i will do rollback because the -rdiff ot i need to find a solution and implement it on time.
I think there is should be another switch case in the code that gives the user more opportunitites.
04-26-2017 09:12 AM
04-26-2017 09:12 AM
08-06-2017 10:04 PM - edited 08-06-2017 10:04 PM
@Yongjun Zhang Hi Yongjun, Do you think this task can be done in the near new CDH versions?
https://issues.apache.org/jira/browse/HDFS-11706
09-13-2017 07:32 PM
@Yongjun Zhang Hi Yongjun, Do you think this task can be done in the near new CDH versions?
https://issues.apache.org/jira/browse/HDFS-11706