hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Gray" <jg...@apache.org>
Subject Re: Review Request: Fix periodic major compaction (HBASE-2990) and expiration check (HBASE-3083)
Date Thu, 11 Nov 2010 17:53:02 GMT

This is an automatically generated e-mail. To reply, visit:

(Updated 2010-11-11 09:53:02.338546)

Review request for hbase, stack and khemani.


Adds change described in comment to Kannan.  If the oldest file is the result of a major compaction,
we use the latest stamp between the region-level lastMajorTime and this store-level lastMajorTime
(the modification time of the major compacted file).  This should address the issue of dealing
w/ minors upgraded to majors not being accounted for in the region-level lastMajorTime.


This is a somewhat misguided attempt.  It's not done but it shows the fairly simple change
to the actual major compaction code.

The hard part is:

+    long lastMajor = region.getRegionInfo().getRegionData().getLastMajor();

And the question is where to persist that.

This patch adds a new class called HRegionData into HRegionInfo that contains any number of
key-value pairs of data that get persisted with the HRI.  Not really sure how I ended up there
but this data seemed like an odd-man-out so adding another field seemed weird.  We also need
some kind of versioning in HRI so we can add stuff w/o migrating.  There's some versioned
stuff in HRData.

Just looking for some feedback / ideas.

This addresses bugs HBASE-2990 and HBASE-3083.

Diffs (updated)

  trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java 1034008 
  trunk/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java 1034008 

Diff: http://review.cloudera.org/r/1089/diff




View raw message