[
https://issues.apache.org/jira/browse/HBASE-3976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13188784#comment-13188784
]
Mikhail Bautin commented on HBASE-3976:
---------------------------------------
The last commit I can see for this JIRA is the following:
{quote}
Author: stack <stack@13f79535-47bb-0310-9956-ffa450edef68>
Date: Tue Jun 14 16:47:37 2011
HBASE-3976 Disable Block Cache On Compactions -- REVERT
{quote}
This makes me think this path was actually reverted in trunk. Besides, when
Jonathan's HBASE-4422 (CacheConfig) went in, it completely changed the way this
feature would be implemented. This is why it is not possible to verify whether
the patch has been applied or not anymore from looking at the current version
of Store.java in trunk. I can't say off the top of my head whether we cache
blocks on write during compactions in HBase trunk these days with the new logic
implemented by HBASE-4422 in effect. However, I am planning to write a new unit
test for both trunk and 89-fb to verify that, and address this JIRA if
necessary in a consistent way across the two branches.
> Disable Block Cache On Compactions
> ----------------------------------
>
> Key: HBASE-3976
> URL: https://issues.apache.org/jira/browse/HBASE-3976
> Project: HBase
> Issue Type: Improvement
> Components: regionserver
> Affects Versions: 0.90.3
> Reporter: Karthick Sankarachary
> Assignee: Nicolas Spiegelberg
> Priority: Minor
> Attachments: HBASE-3976-V3.patch, HBASE-3976-unconditional.patch,
> HBASE-3976.patch
>
>
> Is there a good reason to believe that caching blocks during compactions is
> beneficial? Currently, if block cache is enabled on a certain family, then
> every time it's compacted, we load all of its blocks into the (LRU) cache, at
> the expense of the legitimately hot ones.
> As a matter of fact, this concern was raised earlier in HBASE-1597, which
> rightly points out that, "we should not bog down the LRU with unneccessary
> blocks" during compaction. Even though that issue has been marked as "fixed",
> it looks like it ought to be reopened.
> Should we err on the side of caution and not cache blocks during compactions
> period (as illustrated in the attached patch)? Or, can we be selectively
> aggressive about what blocks do get cached during compaction (e.g., only
> cache those blocks from the recent files)?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
