[
https://issues.apache.org/jira/browse/HBASE-9870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13811491#comment-13811491
]
Jimmy Xiang commented on HBASE-9870:
------------------------------------
[~ndimiduk], apply the patches of 9792 and 9757 to trunk, then run ITBLL, it
will fail with data loss. After you comment out "new
ChangeEncodingAction(tableName)," in SlowDeterministicMonkeyFactory, you run
ITBLL again, it will pass.
> HFileDataBlockEncoderImpl#diskToCacheFormat uses wrong format
> -------------------------------------------------------------
>
> Key: HBASE-9870
> URL: https://issues.apache.org/jira/browse/HBASE-9870
> Project: HBase
> Issue Type: Bug
> Reporter: Jimmy Xiang
>
> In this method, we have
> {code}
> if (block.getBlockType() == BlockType.ENCODED_DATA) {
> if (block.getDataBlockEncodingId() == onDisk.getId()) {
> // The block is already in the desired in-cache encoding.
> return block;
> }
> {code}
> This assumes onDisk encoding is the same as that of inCache. This is not
> true when we change the encoding of a CF. This could be one of the reasons I
> got data loss with online encoding change?
> If I make sure onDisk == inCache all the time, my ITBLL with online encoding
> change worked once for me.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
