[
https://issues.apache.org/jira/browse/HDFS-6647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14056791#comment-14056791
]
Aaron T. Myers commented on HDFS-6647:
--------------------------------------
Thanks for all the comments, y'all. I agree with what everyone has said here.
While we're on the subject, does it not seem strange to anyone that we allow
the INode to still be considered under construction in a snapshot after it's
been deleted from the present FS? I'm thinking that perhaps in addition to this
change that Kihwal has in this patch we should make delete finalize the INode
as well. I think that would've prevented this issue as well, since the current
check in {{checkUCBlock}} would have failed. We could of course do that as a
separate JIRA, or perhaps not at all if we think this is sufficient as-is.
The patch that Kihwal provided looks good to me. One small comment is that it'd
be good to use {{GenericTestUtils#assertExceptionContains}} in the test case to
ensure the correct exception is thrown, but that's pretty minor. +1 once that's
addressed, either by changing the patch or by telling me I'm being too pedantic.
Kihwal - can I go ahead and assign this JIRA to you?
> Edit log corruption when pipeline recovery occurs for deleted file present in
> snapshot
> --------------------------------------------------------------------------------------
>
> Key: HDFS-6647
> URL: https://issues.apache.org/jira/browse/HDFS-6647
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode, snapshots
> Affects Versions: 2.4.1
> Reporter: Aaron T. Myers
> Priority: Blocker
> Attachments: HDFS-6647-failing-test.patch, HDFS-6647.patch
>
>
> I've encountered a situation wherein an OP_UPDATE_BLOCKS can appear in the
> edit log for a file after an OP_DELETE has previously been logged for that
> file. Such an edit log sequence cannot then be successfully read by the
> NameNode.
> More details in the first comment.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
