[ 
https://issues.apache.org/jira/browse/HDFS-3521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295959#comment-13295959
 ] 

Tsz Wo (Nicholas), SZE commented on HDFS-3521:
----------------------------------------------

> Ok. Since I noticed that there are a bunch of people watching this JIRA, but 
> nobody watching HDFS-3540 (yet?), I hope you don't mind if I repost this 
> comment twice. I do apologize for the potential inbox spam.

HDFS-3540 just has be created.  If people are interested in the further 
discussion, they will watch it.  If they don't watch the new JIRA and they are 
not very interested in it, we cannot force them.  I indeed mind if anyone keeps 
posting the same comment on two different JIRAs.

> ... I do not think any people like that exist!

As mentioned by Suresh, edit log toleration is a very useful.
                
> Allow namenode to tolerate edit log corruption
> ----------------------------------------------
>
>                 Key: HDFS-3521
>                 URL: https://issues.apache.org/jira/browse/HDFS-3521
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: name-node
>            Reporter: Tsz Wo (Nicholas), SZE
>            Assignee: Tsz Wo (Nicholas), SZE
>             Fix For: 1.2.0
>
>         Attachments: h3521_20120610_b-1.patch, h3521_20120611_b-1.0.patch, 
> h3521_20120611_b-1.patch
>
>
> HDFS-3479 adds checking for edit log corruption. It uses a fixed 
> UNCHECKED_REGION_LENGTH (=PREALLOCATION_LENGTH) so that the bytes at the end 
> within the length is not checked.  Instead of not checking the bytes, we 
> should check everything and allow toleration.

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

        

Reply via email to