Are these full paths in above or partials? Hopefully the latter (in case hbase.rootdir gets moved).
Good point, I think they are absolute paths for now. I'll change that.
Do we need this class, CompactionDescriptor?
I don't know, you tell me It was in the v4 patch, so I kept it. Let me get rid of it, we can just use the PB object directly as you said.
Is there enough to ensure that this is a compaction edit?
If METAFAMILY we call getCompaction() which does check the row, cf, and column. If not just returns null. I was thinking of adding a new Type in KeyValue, smt like Marker, so that we do not hack around METAFAMILY. wdyt, I can do a follow up issue.
createFlush Is this used?
It is not used after
HBASE-7329. I should remove it. One thing we discussed offline with Sergey was that, if WAL disabled or deferred, a RS that lost the region, might still try to do a flush on entries that did not go into WAL. In these case, we might be writing a file to the region after the we lost the control of the region, but it should be fine since either:
(1) the entries in the flushed file went into WAL already, so we would just be adding a redundant file to the region.
(2) the entries did not go into WAL, but will be flushed into the region. They will or will not be immediately seen by the region, because the region might be already open. They will be seen by subsequent region opens.
Both cases should be fine as far as i can tell though, because for (1), we rely on idempotent edits, for (2) since wal is deferred/skipped these cases would be semantically acceptable.