[ 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.