guihecheng commented on PR #3361: URL: https://github.com/apache/ozone/pull/3361#issuecomment-1118109166
> There two things we discussed: Generating containers locally first and transfer them to the remaining targets. This will give some advantage on failure handling side. Me and Arpit had a short discussion on this. If we stream the container content to avoid local storage consumption, the failure probability is more as we may have longer time spending in NW IO ( prone to failures). Where if we generate them locally, we can transfer the whole container as single step and even if failed to transfer, we could retry. So, it would be good idea to start with generating container locally and transfer them once all recovery done. > > So, the next question for discussion here, while generating locally, whether to use existing protocols and have different container state or use this patch proposed new interfaces. Yes, Uma, I think we need an open discussion around these ideas. For the "Generating containers locally then transfer" idea, I think there is an issue to consider: For Ratis Replication, on a Healthy DN, we have a existing container to export as a tarball, then other DNs come to read them and then import locally. For EC Offline Recovery, on a CoordinatorDN, we'll have several container replicas on disk **with the same containerID**, so we can't have them all in a normal place as Ratis Replication, then we can't reuse the `exportContainer` API easily, we still need to put these container replicas in a temp location and do a special `export` for them(may be by some refactoring and reuse around the existing `exportContainer` API). I mean that the simple approach doesn't seems that simple actually, and if it is not the final ideal solution, why bother cook it? Actually for now, I tends to support the idea from Stephen, we could introduce a new state "RECOVERING" for containers, maybe it is not so easy and need some changes around existing logics, but after it is done, it should be very useful and clean as I imagined. Let's discuss more about these ideas. -- 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]
