Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Fri, 11 May 2012 03:26:03 +0000 (UTC)
From: "Colin Patrick McCabe (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: 
 <1086249123.53023.1336706763938.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <437643778.4197.1335558050636.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (HDFS-3335) check for edit log corruption at the
 end of the log
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/HDFS-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Colin Patrick McCabe updated HDFS-3335:
---------------------------------------

    Attachment: HDFS-3335.008.patch

* EditLogFileInputStream: warn when skipping the last few bytes in a file.

* rename GarbageAfterTerminatorException#offset to numAfterTerminator.

* Rename FSImage#setEditLog to FSImage#setEditLogForTesting and add @VisibleForTesting annotation to it

* avoid making some unecessary whitespace changes
                
> 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, HDFS-3335.008.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