Skip to content

Conversation

@jojochuang
Copy link
Contributor

What changes were proposed in this pull request?

Skeleton code for supporting incremental chunk list in PutBlock. See HDDS-8047 for the problem description and design doc.

Please describe your PR in detail:

  • Add a new rocksdb table lastChunkInfoTable to store the last, in-progress, partial chunk of blocks. (Question: does adding a new table require a new schema version v4? do we need additional code to support upgrade?)
  • Add a Client configuration switch incremental.chunk.list for clients to send incremental chunk list in PutBlock.
  • Add a new client version INCREMENTAL_CHUNK_LIST_SUPPORT (this version change may not be required)

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-9750

How was this patch tested?

Skeleton code. No functional change.

@jojochuang jojochuang requested a review from errose28 November 22, 2023 19:56
@jojochuang jojochuang changed the title Hdds 9750 HDDS-9750. [hsync] Make Putblock performance acceptable - Skeleton code Nov 22, 2023
@ChenSammi
Copy link
Contributor

ChenSammi commented Nov 27, 2023

There is one HDDSLayoutFeature.java to record any new features on DN side. @jojochuang , I think we should add one new item in HDDSLayoutFeature too since we add a new CF for every container.

@ChenSammi
Copy link
Contributor

cc @ashishkumar50 , could you help to take a review too?

Copy link
Contributor

@ashishkumar50 ashishkumar50 left a comment

Choose a reason for hiding this comment

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

@jojochuang, Thanks for the patch.
When new version client connects with the old version DN, in that case chunklist will be only the last chunks which new client will send. Does this case is considered?

@Override
public long putBlock(Container container, BlockData data, boolean endOfBlock)
throws IOException {
return putBlock(container, data, endOfBlock, true);
Copy link
Contributor

Choose a reason for hiding this comment

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

By default can we keep incremental as false so that current behaviour remains same?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

i'm going to refactor this one to make it clear, but basically the client side will have a flag in PutBlock request to hint it carries incremental chunk list. If the flag is false it falls back to the original behavior.

"This client version has support for Object Store and File " +
"System Optimized Bucket Layouts."),
INCREMENTAL_CHUNK_LIST_SUPPORT(4,
"This client version has support for incremental chunk list."),
Copy link
Contributor Author

Choose a reason for hiding this comment

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

this is not needed. will remove.

@jojochuang
Copy link
Contributor Author

jojochuang commented Dec 7, 2023

When new version client connects with the old version DN, in that case chunklist will be only the last chunks which new client will send. Does this case is considered?

Good question. Checking the code we don't seem to have a framework to detect DataNode version from client side? If so I'd leave it later to implement it in HDDS-9753.

Another guardrail to implement is reject new clients from sending incremental chunk list in PutBlock for blocks in schema v1~v3.

@jojochuang
Copy link
Contributor Author

jojochuang commented Dec 7, 2023

There is one HDDSLayoutFeature.java to record any new features on DN side. @jojochuang , I think we should add one new item in HDDSLayoutFeature too since we add a new CF for every container.

My understanding, according to https://github.com/facebook/rocksdb/wiki/Column-Families is that adding/droping RocksDB CF doesn't require any extra work. So perhaps no need for a schema v4? Just make sure that this feature (use the new CF) is activated after upgrade is finalized.

@jojochuang
Copy link
Contributor Author

When new version client connects with the old version DN, in that case chunklist will be only the last chunks which new client will send. Does this case is considered?

We need to fix HDDS-9884 first for clients to be able to tell DataNode version.

Change-Id: I2a92d9137bcb1ed7a91f465cf26046ab1d8b1857

Fix checkstyle

Change-Id: Ifdd3b0f088d7d60adb50063bdc5e2e67392c5bd9

Refactor code and address review comments.

Add a layout feature and reject incremental chunk list requests if the layout version is not finalized.

Add config ozone.chunk.list.incremental to ozone-default.xml.
Copy link
Contributor

@ashishkumar50 ashishkumar50 left a comment

Choose a reason for hiding this comment

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

@jojochuang Thanks for updating patch. Overall LGTM, just a minor suggestion.

throws IOException {
boolean incrementalEnabled =
config.getBoolean(OZONE_CHUNK_LIST_INCREMENTAL,
OZONE_CHUNK_LIST_INCREMENTAL_DEFAULT);
Copy link
Contributor

Choose a reason for hiding this comment

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

Getting OZONE_CHUNK_LIST_INCREMENTAL can move to BlockManagerImpl constructor to avoid reading in every putBlock call.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah I understand but this is a static method, and it uses less than 0.1% of CPU time

HADOOP_PRC_PORTS_IN_DATANODEDETAILS(7, "Adding Hadoop RPC ports " +
"to DatanodeDetails.");
"to DatanodeDetails."),
LAST_CHUNK_TABLE(8, "Datanode RocksDB Schema Version 3 has an extra table " +
Copy link
Contributor

@ChenSammi ChenSammi Jan 10, 2024

Choose a reason for hiding this comment

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

  1. How about change the feature name to HBASE_SUPPORT? For file recovery, a new table finalize_blocks is also introduced. So for HBASE, as of now, two new tables are introduced for it. So if use the name HBASE_SUPPORT, we can cover these two new tables, and also the potential new changes in later.
  2. We should support both Schema V3 and Schema V2. For an existing Ozone cluster with older version, it's likely there will be open Schema V2 containers there.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok

// Create DB store for a newly formatted volume
if (VersionedDatanodeFeatures.isFinalized(
HDDSLayoutFeature.DATANODE_SCHEMA_V3)) {
HDDSLayoutFeature.LAST_CHUNK_TABLE)) {
Copy link
Contributor

@ChenSammi ChenSammi Jan 10, 2024

Choose a reason for hiding this comment

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

This change is not necessary. Let's keep the current code. DATANODE_SCHEMA_V3 will be easy to understand this part logic.

BlockData data, ConfigurationSource config, boolean endOfBlock)
throws IOException {
boolean incrementalEnabled =
config.getBoolean(OZONE_CHUNK_LIST_INCREMENTAL,
Copy link
Contributor

@ChenSammi ChenSammi Jan 10, 2024

Choose a reason for hiding this comment

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

The indent here looks like 8. It's expected to be 4. It's odd that there is no checkstyle warning.

Copy link
Contributor

@ChenSammi ChenSammi left a comment

Choose a reason for hiding this comment

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

The last patch looks good to me.

@jojochuang jojochuang merged commit 5d91635 into apache:HDDS-7593 Jan 11, 2024
jojochuang added a commit to jojochuang/ozone that referenced this pull request Jan 17, 2024
jojochuang added a commit to jojochuang/ozone that referenced this pull request Jan 17, 2024
jojochuang added a commit to jojochuang/ozone that referenced this pull request Jan 17, 2024
@jojochuang jojochuang added the hbase HBase on Ozone support label Jan 23, 2024
chungen0126 pushed a commit to chungen0126/ozone that referenced this pull request May 3, 2024
chungen0126 pushed a commit to chungen0126/ozone that referenced this pull request May 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

hbase HBase on Ozone support

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants