[
https://issues.apache.org/jira/browse/HBASE-10752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13937476#comment-13937476
]
chunhui shen commented on HBASE-10752:
--------------------------------------
For me, I think we don't need to do the 'DataBlockEncoding' check in Trunk.
A cache key (File Name + offset) would map to an unique data block. (In 0.94,
be able to map to two data blocks,so we need this check)
Thus, no need to pass the expected DataBlockEncoding to readBlock().
However, I'm not very sure for the above point, and doing this seems no harm.
Patch is good for me if no others give comment about it.
> Port HBASE-10270 'Remove DataBlockEncoding from BlockCacheKey' to trunk
> -----------------------------------------------------------------------
>
> Key: HBASE-10752
> URL: https://issues.apache.org/jira/browse/HBASE-10752
> Project: HBase
> Issue Type: Improvement
> Reporter: Ted Yu
> Assignee: Ted Yu
> Priority: Minor
> Fix For: 0.99.0
>
> Attachments: 10752-v1.txt, 10752-v2.txt, 10752-v3.txt
>
>
> The JIRA removes the block encoding from the key and forces the caller of
> HFileReaderV2.readBlock() to specify the expected BlockType as well as the
> expected DataBlockEncoding when these matter. This allows for a decision on
> either of these at read time instead of cache time, puts responsibility where
> appropriate, fixes some cache misses when using the scan preloading (which
> does a read without knowing the type or encoding), allows for the
> BlockCacheKey to be re-used by the L2 BucketCache and sets us up for a future
> CompoundScannerV2 which can read both un-encoded and encoded data blocks.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
