[
https://issues.apache.org/jira/browse/HBASE-18693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16754754#comment-16754754
]
Hadoop QA commented on HBASE-18693:
-----------------------------------
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 7s{color}
| {color:red} HBASE-18693 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.8.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-18693 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12895096/HBASE-18693.master.003.patch
|
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/15765/console |
| Powered by | Apache Yetus 0.8.0 http://yetus.apache.org |
This message was automatically generated.
> adding an option to restore_snapshot to move mob files from archive dir to
> working dir
> --------------------------------------------------------------------------------------
>
> Key: HBASE-18693
> URL: https://issues.apache.org/jira/browse/HBASE-18693
> Project: HBase
> Issue Type: Improvement
> Components: mob
> Affects Versions: 2.0.0-alpha-2
> Reporter: huaxiang sun
> Assignee: huaxiang sun
> Priority: Major
> Attachments: HBASE-18693.master.001.patch,
> HBASE-18693.master.002.patch, HBASE-18693.master.003.patch
>
>
> Today, there is a single mob region where mob files for all user regions are
> saved. There could be many files (one million) in a single mob directory.
> When one mob table is restored or cloned from snapshot, links are created for
> these mob files. This creates a scaling issue for mob compaction. In mob
> compaction's select() logic, for each hFileLink, it needs to call NN's
> getFileStatus() to get the size of the linked hfile. Assume that one such
> call takes 20ms, 20ms * 1000000 = 6 hours.
> To avoid this overhead, we want to add an option so that restore_snapshot can
> move mob files from archive dir to working dir. clone_snapshot is more
> complicated as it can clone a snapshot to a different table so moving that
> can destroy the snapshot. No option will be added for clone_snapshot.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
