[
https://issues.apache.org/jira/browse/HBASE-9648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13782406#comment-13782406
]
Lars Hofhansl commented on HBASE-9648:
--------------------------------------
I might be misunderstanding the issue...
When hbase.store.delete.expired.storefile is true an old storefile is nuked
immediately as part of the selection process (rather than being compacted and
then deleted). The issue is when we only have a single store file left and it
is expired, in that case we nuke, but write a new (empty) one to keep the
sequenceId; this file is then nuked (because we return -1 from
getMaxTimestamp() for empty files), and from here we repeat the same cycle.
Another apparent issue is the ratio based selection with empty files.
> 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)
