[
https://issues.apache.org/jira/browse/HBASE-4344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112225#comment-13112225
]
Lars Hofhansl commented on HBASE-4344:
--------------------------------------
The problem with TestStoreFile.testCacheOnWriteEvictOnClose is that
KeyValue.getLength() does not necessarily reflect its actual size on disk any
longer. The fix turns out to simple:
In TestStoreFile.writeStoreFiele:
{code}
for (int i=numKVs;i>0;i--) {
KeyValue kv = new KeyValue(b, b, b, i, b);
kvs.add(kv);
- totalSize += kv.getLength();
+ totalSize += kv.getLength()+Bytes.SIZEOF_LONG;
}
{code}
But it shows a kind of "unpleasantness" of this change.
I am getting a bit weary about this change. If we cannot rely
KeyValue.getLength() when it comes to storage, what other problems are we going
to run into?
> Persist memstoreTS to disk
> --------------------------
>
> Key: HBASE-4344
> URL: https://issues.apache.org/jira/browse/HBASE-4344
> Project: HBase
> Issue Type: Sub-task
> Reporter: Amitanand Aiyer
> Assignee: Amitanand Aiyer
> Fix For: 0.89.20100924
>
> Attachments: 4344-v2.txt, 4344-v4.txt, patch-2
>
>
> Atomicity can be achieved in two ways -- (i) by using a multiversion
> concurrency system (MVCC), or (ii) by ensuring that "new" writes do not
> complete, until the "old" reads complete.
> Currently, Memstore uses something along the lines of MVCC (called RWCC for
> read-write-consistency-control). But, this mechanism is not incorporated for
> the key-values written to the disk, as they do not include the memstore TS.
> Let us make the two approaches be similar, by persisting the memstoreTS along
> with the key-value when it is written to the disk.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
