[
https://issues.apache.org/jira/browse/HDFS-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12769017#action_12769017
]
Konstantin Shvachko commented on HDFS-654:
------------------------------------------
# {{FSNamesystem.renameTo()}} should not be public.
# format new methods to fit 80 symbol boundary.
# In the new {{FSDirectory.unprotectedRenameTo()}} if
{{collectSubtreeBlocksAndClear()}} throws a RuntimeException in line 649, then
frinalized section will try to put {{removedDst}} back in the treeeven though
there the {{renamedSrc}} is already there. I propose to move the assignment
"{{removedDst = null;}}" three lines up.
# In {{FSEditLog.loadEditRecords()}} you should follow the same naming
convention with statistical variables {{numOpRename}} as with the operation
constants:
{{numOpRename}} should count new renames, and {{numOpRenameOld}} - the old ones.
This is only a log message, but it is going to be confusing otherwise.
# Is OIV will be able to read new rename edit log records? Just adding the new
supported version probably does not fix the reading problem by itself.
> HDFS needs to support new rename introduced for FileContext
> -----------------------------------------------------------
>
> Key: HDFS-654
> URL: https://issues.apache.org/jira/browse/HDFS-654
> Project: Hadoop HDFS
> Issue Type: New Feature
> Affects Versions: 0.21.0
> Reporter: Suresh Srinivas
> Assignee: Suresh Srinivas
> Fix For: 0.22.0
>
> Attachments: hdfs-654.1.patch, hdfs-654.2.patch, hdfs-654.3.patch,
> hdfs-654.5.patch, hdfs-654.5.patch, hdfs-654.7.patch, HDFS-654.patch
>
>
> New rename functionality with different semantics to overwrite the existing
> destination was introduced for use in FileContext. Currently the default
> implementation in FileSystem is not atomic. This change implements atomic
> rename operation for use by FileContext.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
