[ https://issues.apache.org/jira/browse/HDFS-10115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vinayakumar B deleted HDFS-10115: --------------------------------- > CLONE - Fix a decoding issue in stripped block recovering in client side > ------------------------------------------------------------------------ > > Key: HDFS-10115 > URL: https://issues.apache.org/jira/browse/HDFS-10115 > Project: Hadoop HDFS > Issue Type: Sub-task > Reporter: dragon > Assignee: Kai Zheng > > [~jingzhao] reported a decoding issue in HDFS-8481 in the comment copied > below: > bq. While debugging HDFS-8319, I just found that in > TestWriteReadStripedFile#testWritePreadWithDNFailure, if we change the > startOffsetInFile from cellSize * 5 to 0, the test fails with the following > error msg: > {noformat} > java.lang.AssertionError: Byte at 524288 should be the same expected:<27> but > was:<-9> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:743) > at org.junit.Assert.assertEquals(Assert.java:118) > at org.junit.Assert.assertEquals(Assert.java:555) > at > org.apache.hadoop.hdfs.TestWriteReadStripedFile.testWritePreadWithDNFailure(TestWriteReadStripedFile.java:390) > {noformat} > It was caused by an issue that we need to adjust the inputs order to call > decoder#decode. When startOffsetInFile is 5 * cellSize, the recovering or > decoding won't be needed as ZERO cells don't need to recover; when it's 0, > the issue then was exposed, as normal data cells must be recovered thru the > decoding. -- This message was sent by Atlassian JIRA (v6.3.4#6332)