Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Sun, 30 Jul 2017 12:21:02 +0000 (UTC)
From: "stack (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12938259.1455127316000.46417.1501417262145@Atlassian.JIRA>
In-Reply-To: <JIRA.12938259.1455127316000@Atlassian.JIRA>
References: <JIRA.12938259.1455127316000@Atlassian.JIRA> <JIRA.12938259.1455127316287@jira-lw-us.apache.org>
Subject: [jira] [Commented] (HBASE-15248) BLOCKSIZE 4k should result in 4096
 bytes on disk; i.e. fit inside a BucketCache 'block' of 4k
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Sun, 30 Jul 2017 12:21:11 -0000


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

stack commented on HBASE-15248:
-------------------------------

That is right [~anoop.hbase]  There is tail data too... the CRCs.

This issue is about "...what it would take to stay inside our configured size boundary writing out blocks ...."  or ".....give back better signal on what to do so you could fit inside a particular constraint." ... so if user says 4k, then we'd only write 4k blocks (the 4k would include metadata and CRCs...).   As [~ndimiduk] says, the 4k doesn't count compression + encryption.. but maybe a first pass would fix case when not compression or encoding?


> BLOCKSIZE 4k should result in 4096 bytes on disk; i.e. fit inside a BucketCache 'block' of 4k
> ---------------------------------------------------------------------------------------------
>
>                 Key: HBASE-15248
>                 URL: https://issues.apache.org/jira/browse/HBASE-15248
>             Project: HBase
>          Issue Type: Sub-task
>          Components: BucketCache
>            Reporter: stack
>
> Chatting w/ a gentleman named Daniel Pol who is messing w/ bucketcache, he wants blocks to be the size specified in the configuration and no bigger. His hardware set ups fetches pages of 4k and so a block that has 4k of payload but has then a header and the header of the next block (which helps figure whats next when scanning) ends up being 4203 bytes or something, and this then then translates into two seeks per block fetch.
> This issue is about what it would take to stay inside our configured size boundary writing out blocks.
> If not possible, give back better signal on what to do so you could fit inside a particular constraint.


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)