[
https://issues.apache.org/jira/browse/HADOOP-12884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15178337#comment-15178337
]
Chris Nauroth commented on HADOOP-12884:
----------------------------------------
Hello [~liushaohui]. There have been several recent bug fixes in this area.
Please see HADOOP-12634 and HADOOP-12780. If it looks like these address the
problem you saw, then would you please close this as a duplicate issue? Thank
you.
Cc [~gouravk], [~madhuch-ms], [~onpduo], [~dchickabasapa].
> A failed atomic folder rename operation can never recovery for the
> destination file is deleted in Wasb filesystem
> -----------------------------------------------------------------------------------------------------------------
>
> Key: HADOOP-12884
> URL: https://issues.apache.org/jira/browse/HADOOP-12884
> Project: Hadoop Common
> Issue Type: Bug
> Reporter: Liu Shaohui
> Priority: Critical
>
> When using Wsab file system, we found that a failed atomic folder rename
> operation can never recovery for the destination file deleted in Wasb
> filesystem.
> {code}
> ls: Attempting to complete rename of file
> hbase/azurtst-xiaomi/data/default/YCSBTest/.tabledesc during folder rename
> redo, and file was not found in source or destination.
> {code}
> The reason is the the file is renamed to the destination file before the
> crash, and the destination file is deleted by another process after crash. So
> the recovery is blocked during finishing the rename operation of this file
> when found the source and destination files all don't exist.
> See: NativeAzureFileSystem.java #finishSingleFileRename
> Another serious problem is that the recovery of atomic rename operation may
> delete new created file which is same name as the source file, because the
> file system don't check if there are rename operation need be redo.
> Suggestions are welcomed~
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
