[
https://issues.apache.org/jira/browse/HDFS-4849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13667071#comment-13667071
]
Steve Loughran commented on HDFS-4849:
--------------------------------------
This is going to break concurrency logic, you realise that?
# client 1: issues recursive delete on dir {{/path}}. dir is deleted, response
gets lost
# client 2: does an atomic rename of a directory to {{/path}} -which succeeds
as there was no file there to stop it
# client 1: re-issues delete. Server destroys result of client2.
This will be visible to client2, as in "potential data loss" visibility. It's
rename action would only succeed if the initial rm succeeded, so this data loss
only occurs due to the retry operation.
I do not see how I could implement it safely on blobstores or even the local
filesystem.
> Idempotent create, append and delete operations.
> ------------------------------------------------
>
> Key: HDFS-4849
> URL: https://issues.apache.org/jira/browse/HDFS-4849
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
> Affects Versions: 2.0.4-alpha
> Reporter: Konstantin Shvachko
> Assignee: Konstantin Shvachko
>
> create, append and delete operations can be made idempotent. This will reduce
> chances for a job or other app failures when NN fails over.
--
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
