[
https://issues.apache.org/jira/browse/HDFS-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13272945#comment-13272945
]
Colin Patrick McCabe commented on HDFS-3335:
--------------------------------------------
* Yeah, your understanding of GarbageAfterTerminatorException#getOffset is
correct. I'll rename it to something clearer.
.bq Part of what is confusing me is this: does padding after OP_INVALID count
as garbage or not?
No, padding is just zeros or 0xffs. Garbage is something you wouldn't expect
to be there, like more opcodes, random bytes, or something like that.
* I'll see if I can remove the unecessary whitespace diffs...
> check for edit log corruption at the end of the log
> ---------------------------------------------------
>
> Key: HDFS-3335
> URL: https://issues.apache.org/jira/browse/HDFS-3335
> Project: Hadoop HDFS
> Issue Type: Improvement
> Affects Versions: 0.23.0
> Reporter: Colin Patrick McCabe
> Assignee: Colin Patrick McCabe
> Attachments: HDFS-3335-b1.001.patch, HDFS-3335-b1.002.patch,
> HDFS-3335-b1.003.patch, HDFS-3335-b1.004.patch, HDFS-3335.001.patch,
> HDFS-3335.002.patch, HDFS-3335.003.patch, HDFS-3335.004.patch,
> HDFS-3335.005.patch, HDFS-3335.006.patch, HDFS-3335.007.patch
>
>
> Even after encountering an OP_INVALID, we should check the end of the edit
> log to make sure that it contains no more edits.
> This will catch things like rare race conditions or log corruptions that
> would otherwise remain undetected. They will got from being silent data loss
> scenarios to being cases that we can detect and fix.
> Using recovery mode, we can choose to ignore the end of the log if necessary.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
