[
https://issues.apache.org/jira/browse/HDFS-4300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13627223#comment-13627223
]
Andrew Wang commented on HDFS-4300:
-----------------------------------
I think this is okay. A storage failure while downloading will blacklist the
storage (I believe until the SNN is restarted), preventing rename. It also
redownloads edits on a future attempt if the final edits file does not exist.
So when we go to rename, we should only be iterating over valid storages with
freshly downloaded files.
> TransferFsImage.downloadEditsToStorage should use a tmp file for destination
> ----------------------------------------------------------------------------
>
> Key: HDFS-4300
> URL: https://issues.apache.org/jira/browse/HDFS-4300
> Project: Hadoop HDFS
> Issue Type: Bug
> Affects Versions: 2.0.2-alpha
> Reporter: Todd Lipcon
> Assignee: Andrew Wang
> Priority: Critical
> Attachments: hdfs-4300-1.patch
>
>
> Currently, in TransferFsImage.downloadEditsToStorage, we download the edits
> file directly to its finalized path. So, if the transfer fails in the middle,
> a half-written file is left and cannot be distinguished from a correct file.
> So, future checkpoints by the 2NN will fail, since the file is truncated in
> the middle -- but it won't ever download a good copy because it thinks it
> already has the proper file.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
