[
https://issues.apache.org/jira/browse/HBASE-5864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260455#comment-13260455
]
ramkrishna.s.vasudevan commented on HBASE-5864:
-----------------------------------------------
The problem is because of using checksums. This problem will be coming based
on the block size and the kv size that are added in HFile.
When we try to read a block, Consider the following code
In BlockIterator.blockRange
{code}
@Override
public HFileBlock nextBlock() throws IOException {
if (offset >= endOffset)
return null;
HFileBlock b = readBlockData(offset, -1, -1, false);
offset += b.getOnDiskSizeWithHeader();
return b;
}
{code}
In case of noncompressed algo in
{code}
private HFileBlock readBlockDataInternal(FSDataInputStream is, long offset,
long onDiskSizeWithHeaderL,
int uncompressedSize, boolean pread, boolean verifyChecksum)
{code}
{code}
b = new HFileBlock(headerBuf, getMinorVersion());
// This will also allocate enough room for the next block's header.
b.allocateBuffer(true);
{code}
Inside allocateBuffer
{code}
int cksumBytes = totalChecksumBytes();
int capacityNeeded = headerSize() + uncompressedSizeWithoutHeader +
cksumBytes +
(extraBytes ? headerSize() : 0);
ByteBuffer newBuf = ByteBuffer.allocate(capacityNeeded);
{code}
This byte allocated for this block is having the checksumbytes also added to it.
After fetching the block and its corresponding stream, we try to get the root
block.
{code}
// Data index. We also read statistics about the block index written after
// the root level.
dataBlockIndexReader.readMultiLevelIndexRoot(
blockIter.nextBlockAsStream(BlockType.ROOT_INDEX),
trailer.getDataIndexCount());
{code}
Inside readMultiLevelIndexRoot
{code}
readRootIndex(in, numEntries);
if (in.available() < MID_KEY_METADATA_SIZE) {
// No mid-key metadata available.
return;
}
{code}
Here the InputStream 'in' is formed from the blk.getByteStream().
Here the inputstream actually will have its available length including the
checksum bytes.
While doing readRootIndex
{code}
public void readRootIndex(DataInput in, final int numEntries)
throws IOException {
{code}
We read only the data and the remaining checksum bytse allocated are still
available with the input stream.
We know that for every 16k data size we have 4 byte check sum.
Now if my data size is ~66k i will have 20bytes check sum. So the
{code}
if (in.available() < MID_KEY_METADATA_SIZE) {
// No mid-key metadata available.
return;
}
{code}
will now be greater than MID_KEY_METADATA_SIZE(16 bytes) and thus giving us
some invalid 'midLeafBlockOffset'.
So when we try to read the file we get some abnormal values. The same can be
reproduced using the testcase.
> Error while reading from hfile in 0.94
> --------------------------------------
>
> Key: HBASE-5864
> URL: https://issues.apache.org/jira/browse/HBASE-5864
> Project: HBase
> Issue Type: Bug
> Components: regionserver
> Affects Versions: 0.94.0
> Reporter: Gopinathan A
> Priority: Critical
> Fix For: 0.94.0
>
>
> Got the following stacktrace during region split.
> {noformat}
> 2012-04-24 16:05:42,168 WARN org.apache.hadoop.hbase.regionserver.Store:
> Failed getting store size for value
> java.io.IOException: Requested block is out of range: 2906737606134037404,
> lastDataBlockOffset: 84764558
> at
> org.apache.hadoop.hbase.io.hfile.HFileReaderV2.readBlock(HFileReaderV2.java:278)
> at
> org.apache.hadoop.hbase.io.hfile.HFileBlockIndex$BlockIndexReader.midkey(HFileBlockIndex.java:285)
> at
> org.apache.hadoop.hbase.io.hfile.HFileReaderV2.midkey(HFileReaderV2.java:402)
> at
> org.apache.hadoop.hbase.regionserver.StoreFile$Reader.midkey(StoreFile.java:1638)
> at
> org.apache.hadoop.hbase.regionserver.Store.getSplitPoint(Store.java:1943)
> at
> org.apache.hadoop.hbase.regionserver.RegionSplitPolicy.getSplitPoint(RegionSplitPolicy.java:77)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.checkSplit(HRegion.java:4921)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.splitRegion(HRegionServer.java:2901)
> {noformat}
--
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
