Skip to content

HBASE-28177 Fix mobStore directory do not set storage policy - #6385

Open
xieyupei wants to merge 9 commits into
apache:masterfrom
xieyupei:master
Open

HBASE-28177 Fix mobStore directory do not set storage policy#6385
xieyupei wants to merge 9 commits into
apache:masterfrom
xieyupei:master

Conversation

@xieyupei

Copy link
Copy Markdown
Contributor

No description provided.

private AtomicLong majorCompactedCellsSize = new AtomicLong();

private final StoreContext storeContext;
protected String policyName;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @xieyupei do we really need this? why not just do String policyName = family.getStoragePolicy(); even in HMobStore.java

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Before this key "hbase.hmobstore.block.storage.policy", i think if we don't have this, we should write the same code in HMobStore.
"Optional.ofNullable(family.getStoragePolicy())
.orElseGet(() -> conf.get(BLOCK_STORAGE_POLICY_KEY, DEFAULT_BLOCK_STORAGE_POLICY))
.trim();
"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes we should do that right?

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, I think so

HRegionFileSystem regionFs = getHRegionFS(TEST_UTIL.getConnection(), table, conf);
try (Admin admin = TEST_UTIL.getConnection().getAdmin()) {
ColumnFamilyDescriptorBuilder cfdA = ColumnFamilyDescriptorBuilder.newBuilder(FAMILIES[0]);
cfdA.setValue(HStore.BLOCK_STORAGE_POLICY_KEY, "ONE_SSD");

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add a new key: "hbase.hmobstore.block.storage.policy"

I am not sure if this JIRA is a bug or a new feature. But teh change will definitely change behaviour for exisdting users once this patch is merged

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, i agree. what about the "hbase.hmobstore.block.storage.policy" default value? equals hstore or just none?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we need to add this new key, because when we creat a table, we set the STORAGE-POLICY configuration or ues the default policy (HStore.BLOCK_STORAGE_POLICY_KEY), which means that all data under this column family should follow this policy.
So, the storage strategy for MOB should be consistent with the column family.

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We discovered this issue when we found incorrect storage capacity in our cluster. We believe this is a bug, so I fix it like this pr, but I'm not sure how this is determined in our community. @NihalJain@guluo2016

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We believe this is a bug, so I fix it like this pr

I agree with you.

but I'm not sure how this is determined in our community.

In my personal opinion, the storage strategy for MOB should be consistent with the column family.
Perhaps we can discuss it with Nihal and others together.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am fine with consolidating with mobstore as that is the right way. My only concern is we may unknowingly start moving data around if this silently lands with a new version upgrade. May be we are okay to just add to release note, since that would be a behavioral change (due to bug).

Hey @Apache9 WDYT?

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR has been around for a while, may not have noticed, remind. @Apache9

@Apache-HBase

Copy link
Copy Markdown

💔 -1 overall

VoteSubsystemRuntimeLogfileComment
+0 🆗reexec0m 18sDocker mode activated.
_ Prechecks _
+1 💚dupname0m 0sNo case conflicting files found.
+0 🆗codespell0m 0scodespell was not available.
+0 🆗detsecrets0m 0sdetect-secrets was not available.
+1 💚@author0m 0sThe patch does not contain any @author tags.
+1 💚hbaseanti0m 0sPatch does not have any anti-patterns.
_ master Compile Tests _
+1 💚mvninstall3m 0smaster passed
+1 💚compile2m 54smaster passed
+1 💚checkstyle0m 37smaster passed
-1 ❌spotbugs1m 32s/branch-spotbugs-hbase-server-warnings.htmlhbase-server in master has 1 extant spotbugs warnings.
+1 💚spotless0m 45sbranch has no errors when running spotless:check.
_ Patch Compile Tests _
+1 💚mvninstall2m 51sthe patch passed
+1 💚compile2m 54sthe patch passed
+1 💚javac2m 54sthe patch passed
+1 💚blanks0m 0sThe patch has no blanks issues.
+1 💚checkstyle0m 37sthe patch passed
+1 💚spotbugs1m 40sthe patch passed
+1 💚hadoopcheck10m 5sPatch does not cause any errors with Hadoop 3.3.6 3.4.0.
-1 ❌spotless0m 37spatch has 57 errors when running spotless:check, run spotless:apply to fix.
_ Other Tests _
+1 💚asflicense0m 12sThe patch does not generate ASF License warnings.
34m 30s
SubsystemReport/Notes
DockerClientAPI=1.47 ServerAPI=1.47 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6385/1/artifact/yetus-general-check/output/Dockerfile
GITHUB PR#6385
Optional Testsdupname asflicense javac spotbugs checkstyle codespell detsecrets compile hadoopcheck hbaseanti spotless
unameLinux 6c87bd5544ba 5.4.0-192-generic #212-Ubuntu SMP Fri Jul 5 09:47:39 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
Build toolmaven
Personalitydev-support/hbase-personality.sh
git revisionmaster / 2834c1c
Default JavaEclipse Adoptium-17.0.11+9
spotlesshttps://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6385/1/artifact/yetus-general-check/output/patch-spotless.txt
Max. process+thread count83 (vs. ulimit of 30000)
modulesC: hbase-server U: hbase-server
Console outputhttps://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6385/1/console
versionsgit=2.34.1 maven=3.9.8 spotbugs=4.7.3
Powered byApache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

@Apache-HBase

Copy link
Copy Markdown

🎊 +1 overall

VoteSubsystemRuntimeLogfileComment
+0 🆗reexec0m 26sDocker mode activated.
-0 ⚠️yetus0m 2sUnprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --author-ignore-list --blanks-eol-ignore-file --blanks-tabs-ignore-file --quick-hadoopcheck
_ Prechecks _
_ master Compile Tests _
+1 💚mvninstall2m 56smaster passed
+1 💚compile0m 51smaster passed
+1 💚javadoc0m 26smaster passed
+1 💚shadedjars5m 25sbranch has no errors when building our shaded downstream artifacts.
_ Patch Compile Tests _
+1 💚mvninstall2m 48sthe patch passed
+1 💚compile0m 54sthe patch passed
+1 💚javac0m 54sthe patch passed
+1 💚javadoc0m 25sthe patch passed
+1 💚shadedjars5m 22spatch has no errors when building our shaded downstream artifacts.
_ Other Tests _
+1 💚unit205m 55shbase-server in the patch passed.
229m 39s
SubsystemReport/Notes
DockerClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6385/1/artifact/yetus-jdk17-hadoop3-check/output/Dockerfile
GITHUB PR#6385
Optional Testsjavac javadoc unit compile shadedjars
unameLinux 01d276056ddf 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Build toolmaven
Personalitydev-support/hbase-personality.sh
git revisionmaster / 2834c1c
Default JavaEclipse Adoptium-17.0.11+9
Test Resultshttps://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6385/1/testReport/
Max. process+thread count5127 (vs. ulimit of 30000)
modulesC: hbase-server U: hbase-server
Console outputhttps://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6385/1/console
versionsgit=2.34.1 maven=3.9.8
Powered byApache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

policyName = this.conf.get(BLOCK_STORAGE_POLICY_KEY, DEFAULT_BLOCK_STORAGE_POLICY);
}
region.getRegionFileSystem().setStoragePolicy(family.getNameAsString(), policyName.trim());
this.policyName = Optional.ofNullable(family.getStoragePolicy())

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there any change in logic here? Seems same as before just that we are using lambdas now?

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, no logic change. just to simplify assigning values ​​to "this.policyName"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The lambda does not help too much here I'd say.

Let's keep the old way?

String pName = family.getStoragePolicy() != null ? family.getStoragePolicy() : conf.get(BLOCK_STORAGE_POLICY_KEY, DEFAULT_BLOCK_STORAGE_POLICY);
this.policyName = pName.trim();

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, I will do it

@NihalJain
NihalJain requested a review from CopilotMarch 25, 2026 15:12
@NihalJain

Copy link
Copy Markdown
Contributor

Ah missed following up here, sorry for the delay @xieyupei

CopilotAI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR (HBASE-28177) aims to ensure MOB store directories/files correctly inherit the column family storage policy, aligning MOB behavior with normal store files.

Changes:

  • Expose the resolved CF storage policy in HStore for reuse by subclasses.
  • Apply the resolved storage policy to the MOB family directory in HMobStore.
  • Add a regionserver filesystem test validating storage policy inheritance for MOB store files.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

FileDescription
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStore.javaPersist resolved CF storage policy for reuse (e.g., by MOB store).
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HMobStore.javaAttempt to apply CF storage policy to MOB family directory.
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegionFileSystem.javaAdd test coverage for MOB store storage policy behavior.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

xieyupeiand others added 2 commits March 27, 2026 14:56
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
@xieyupei

Copy link
Copy Markdown
ContributorAuthor

Ah missed following up here, sorry for the delay @xieyupei
Thanks for your attention, I also forget this PR for long time. @NihalJain

@xieyupei

Copy link
Copy Markdown
ContributorAuthor

@NihalJain Could you please help me what to do next?Is it means this PR is expired?

@NihalJain

Copy link
Copy Markdown
Contributor

Hi @xieyupei lgtm, will wait for more eyes just in case, else merge by tomorrow EOD

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants

@xieyupei@Apache-HBase@NihalJain@Apache9@guluo2016