[
https://issues.apache.org/jira/browse/HBASE-15477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15205835#comment-15205835
]
stack commented on HBASE-15477:
-------------------------------
bq. ....when we have some scans that involves scanning from contiguous blocks.
... and some blocks come from cache and some from HDFS... yeah, we keep the
next-blocks length around and save it in cache so we avoid the need to seek the
next block header before we can read the next block body.
Yeah, we retain this 'optimization' after all. It is not removed. It is
documented on how it provides benefit (Just don't know how much).
> Do not save 'next block header' when we cache hfileblocks
> ---------------------------------------------------------
>
> Key: HBASE-15477
> URL: https://issues.apache.org/jira/browse/HBASE-15477
> Project: HBase
> Issue Type: Sub-task
> Components: BlockCache, Performance
> Reporter: stack
> Assignee: stack
> Attachments: 15366v4.patch, 15477.patch, 15477v2.patch,
> 15477v3.patch, 15477v3.patch, 15477v4.patch
>
>
> When we read from HDFS, we overread to pick up the next blocks header.
> Doing this saves a seek as we move through the hfile; we save having to
> do an explicit seek just to read the block header every time we need to
> read the body. We used to read in the next header as part of the
> current blocks buffer. This buffer was then what got persisted to
> blockcache; so we were over-persisting wrtiting out our block plus the
> next blocks' header (overpersisting 33 bytes). Parse of HFileBlock
> complicated by this extra tail. Fix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
