[
https://issues.apache.org/jira/browse/HBASE-15477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-15477:
--------------------------
Attachment: 15477.patch
First cut. Below is the commit message. This patch actually overdoes it. I'm
going to walk back my purge of a specious looking optimization. As used, there
is no benefit other than complication and exposure of internals but there could
be case where we'd save a seek. Will be back w/ a new patch. Let me see how
this does against hadoopqa in the meantime.
> 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: 15477.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)
