You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Hadoop QA (JIRA)" <ji...@apache.org> on 2016/04/25 06:19:12 UTC
[jira] [Commented] (HBASE-15477) Do not save 'next block header'
when we cache hfileblocks
[ https://issues.apache.org/jira/browse/HBASE-15477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15255865#comment-15255865 ]
Hadoop QA commented on HBASE-15477:
-----------------------------------
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 6s {color} | {color:red} HBASE-15477 does not apply to branch-1. Rebase required? Wrong Branch? See https://yetus.apache.org/documentation/0.2.1/precommit-patchnames for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12800178/15477.backport.branch-1.patch |
| JIRA Issue | HBASE-15477 |
| Console output | https://builds.apache.org/job/PreCommit-HBASE-Build/1577/console |
| Powered by | Apache Yetus 0.2.1 http://yetus.apache.org |
This message was automatically generated.
> 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
> Fix For: 2.0.0
>
> Attachments: 15366v4.patch, 15477.backport.branch-1.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)