hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-15477) Do not save 'next block header' when we cache hfileblocks
Date Fri, 18 Mar 2016 23:30:33 GMT

    [ https://issues.apache.org/jira/browse/HBASE-15477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15202361#comment-15202361
] 

stack commented on HBASE-15477:
-------------------------------

RB won't let me update. The difference from RB is adding to FileContextBuilder a constructor
that takes a FileContext so I can make new context based off a previous changing just the
few items I want to change rather than have to copy all. This fixed unit tests (was using
the checksum type from default filecontext rather than the one gotten from the block read
from hdfs/cache).

> 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
>
>
>     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)

Mime
View raw message