[
https://issues.apache.org/jira/browse/HBASE-9648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13782415#comment-13782415
]
Sergey Shelukhin commented on HBASE-9648:
-----------------------------------------
Yeah, that is the issue. However, it's not just deleted, it goes thru
compaction with a request for one file, then it's at least nominally scanned
(probably it skips the entire file in scanner), committed, etc. etc.
We could just archive it straight away, no compaction or anything.
The fixes previously discussed here were fixing the special case handling for
the creation of new file, as we don't really need to do it as often as we do.
> collection one expired storefile causes it to be replaced by another expired
> storefile
> --------------------------------------------------------------------------------------
>
> Key: HBASE-9648
> URL: https://issues.apache.org/jira/browse/HBASE-9648
> Project: HBase
> Issue Type: Bug
> Components: Compaction
> Reporter: Sergey Shelukhin
> Assignee: Jean-Marc Spaggiari
> Attachments: HBASE-9648-v0-0.94.patch, HBASE-9648-v0-trunk.patch,
> HBASE-9648-v1-trunk.patch
>
>
> There's a shortcut in compaction selection that causes the selection of
> expired store files to quickly delete.
> However, there's also the code that ensures we write at least one file to
> preserve seqnum. This new empty file is "expired", because it has no data,
> presumably.
> So it's collected again, etc.
> This affects 94, probably also 96.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
