You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@ozone.apache.org by er...@apache.org on 2026/07/13 20:12:23 UTC

(ozone-site) branch master updated: HDDS-15746. [Auto] Update configuration documentation (#487)

This is an automated email from the ASF dual-hosted git repository.

errose28 pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/ozone-site.git


The following commit(s) were added to refs/heads/master by this push:
     new f4020c0b8c HDDS-15746. [Auto] Update configuration documentation (#487)
f4020c0b8c is described below

commit f4020c0b8cbe7e8576aae77f1b9fae7e041e6866
Author: asf-ci-deploy <82...@users.noreply.github.com>
AuthorDate: Mon Jul 13 22:12:18 2026 +0200

    HDDS-15746. [Auto] Update configuration documentation (#487)
    
    Co-authored-by: github-actions[bot] <gi...@users.noreply.github.com>
---
 docs/05-administrator-guide/02-configuration/99-appendix.md | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/docs/05-administrator-guide/02-configuration/99-appendix.md b/docs/05-administrator-guide/02-configuration/99-appendix.md
index a4c8ff999b..5e0d51bbdb 100644
--- a/docs/05-administrator-guide/02-configuration/99-appendix.md
+++ b/docs/05-administrator-guide/02-configuration/99-appendix.md
@@ -125,17 +125,17 @@ This page provides a comprehensive overview of the configuration keys available
 | `hdds.datanode.disk.balancer.should.run.default` | false | `DATANODE`, `DISKBALANCER` | If DiskBalancer fails to get information from diskbalancer.info, it will choose this value to decide if this service should be running. |
 | `hdds.datanode.disk.balancer.stop.after.disk.even` | true | `DISKBALANCER` | If true, the DiskBalancer will automatically stop once disks are balanced. |
 | `hdds.datanode.disk.balancer.volume.density.threshold.percent` | 10 | `DISKBALANCER` | Threshold is a percentage in the range of 0 to 100. A datanode is considered balanced if for each volume, the utilization of the volume(used space to capacity ratio) differs from the utilization of the datanode(used space to capacity ratio of the entire datanode) no more than the threshold. |
-| `hdds.datanode.disk.check.io.failures.tolerated` | 1 | `DATANODE` | The number of I/O tests out of the last `hdds.datanode.disk.check.io.test.count` test run that are allowed to fail before the volume is marked as failed. |
+| `hdds.datanode.disk.check.io.failures.tolerated` | 1 | `DATANODE` | The number of IO tests out of the last `hdds.datanode.disk.check.io.test.count` test run that are allowed to fail before the volume is marked as failed. |
 | `hdds.datanode.disk.check.io.file.size` | 100B | `DATANODE` | The size of the temporary file that will be synced to the disk and read back to assess its health. The contents of the file will be stored in memory during the duration of the check. |
-| `hdds.datanode.disk.check.io.test.count` | 3 | `DATANODE` | The number of I/O tests required to determine if a disk has failed. Each disk check does one I/O test. The volume will be failed if more than `hdds.datanode.disk.check.io.failures.tolerated` out of the last `hdds.datanode.disk.check.io.test.count` runs failed. Set to 0 to disable disk I/O checks. |
-| `hdds.datanode.disk.check.io.test.enabled` | true | `DATANODE` | The configuration to enable or disable disk I/O checks. |
+| `hdds.datanode.disk.check.io.test.count` | 3 | `DATANODE` | The number of IO tests required to determine if a disk has failed. Each disk check does one IO test. The volume will be failed if more than `hdds.datanode.disk.check.io.failures.tolerated` out of the last `hdds.datanode.disk.check.io.test.count` runs failed. Set to 0 to disable disk IO checks. |
+| `hdds.datanode.disk.check.io.test.enabled` | true | `DATANODE` | The configuration to enable or disable disk IO checks. |
 | `hdds.datanode.disk.check.min.gap` | 10m | `DATANODE` | The minimum gap between two successive checks of the same Datanode volume. Unit could be defined with postfix (ns,ms,s,m,h,d). |
-| `hdds.datanode.disk.check.rocksdb.check.io.test.enabled` | true | `DATANODE` | The configuration to enable or disable RocksDb disk I/O checks. |
+| `hdds.datanode.disk.check.rocksdb.check.io.test.enabled` | true | `DATANODE` | The configuration to enable or disable RocksDb disk IO checks. |
 | `hdds.datanode.disk.check.sliding.window.timeout` | 70m | `DATANODE` | Time interval after which a disk check failure result stored in the sliding window will expire. Do not set the window timeout period to less than or equal to the disk check interval period or failures can be missed across sparse checks e.g., every 120m interval with a 60m window rarely accumulates enough failed events Unit could be defined with postfix (ns,ms,s,m,h,d). |
 | `hdds.datanode.disk.check.timeout` | 10m | `DATANODE` | Maximum allowed time for a disk check to complete. If the check does not complete within this time interval then the disk is declared as failed. Unit could be defined with postfix (ns,ms,s,m,h,d). |
 | `hdds.datanode.disk.check.timeout.failures.tolerated` | 1 | `DATANODE` | The number of volume check timeouts allowed within the timeout sliding window before the volume is marked as failed. |
 | `hdds.datanode.disk.check.timeout.sliding.window.timeout` | 90m | `DATANODE` | Time interval after which a timed out volume check event stored in the timeout sliding window will expire. Do not set this below the periodic disk check interval or timeout events may not accumulate across sparse checks. Unit could be defined with postfix (ns,ms,s,m,h,d). |
-| `hdds.datanode.disk.check.timeout.test.enabled` | true | `DATANODE` | Enable or disable timeout-based volume failure tracking independently of the disk I/O health checks. |
+| `hdds.datanode.disk.check.timeout.test.enabled` | true | `DATANODE` | Enable or disable timeout-based volume failure tracking independently of the disk IO health checks. |
 | `hdds.datanode.dns.interface` | default | `OZONE`, `DATANODE` | The name of the Network Interface from which a Datanode should report its IP address. e.g. eth2. This setting may be required for some multi-homed nodes where the Datanodes are assigned multiple hostnames and it is desirable for the Datanodes to use a non-default hostname. |
 | `hdds.datanode.dns.nameserver` | default | `OZONE`, `DATANODE` | The host name or IP address of the name server (DNS) which a Datanode should use to determine its own host name. |
 | `hdds.datanode.du.factory.classname` |  | `DATANODE` | The fully qualified name of the factory class that creates objects for providing disk space usage information. It should implement the SpaceUsageCheckFactory interface. |
@@ -259,7 +259,6 @@ This page provides a comprehensive overview of the configuration keys available
 | `hdds.scm.replication.maintenance.remaining.redundancy` | 1 | `SCM`, `OZONE` | The number of redundant containers in a group which must be available for a node to enter maintenance. If putting a node into maintenance reduces the redundancy below this value , the node will remain in the ENTERING_MAINTENANCE state until a new replica is created. For Ratis containers, the default value of 1 ensures at least two replicas are online, meaning 1 more can be lost without data becoming unavaila [...]
 | `hdds.scm.replication.maintenance.replica.minimum` | 2 | `SCM`, `OZONE` | The minimum number of container replicas which must be available for a node to enter maintenance. If putting a node into maintenance reduces the available replicas for any container below this level, the node will remain in the entering maintenance state until a new replica is created. |
 | `hdds.scm.replication.over.replicated.interval` | 30s | `SCM`, `OZONE` | How frequently to check if there are work to process on the over replicated queue |
-| `hdds.scm.replication.push` | true | `SCM`, `DATANODE` | If false, replication happens by asking the target to pull from source nodes. If true, the source node is asked to push to the target node. |
 | `hdds.scm.replication.quasi.closed.stuck.best.origin.copies` | 3 | `SCM` | For quasi-closed stuck containers with multiple diverged origins, the number of replicas to maintain for the origin with the highest bcsId among healthy replicas. This origin is considered the 'best' copy and receives extra fault-tolerance. If multiple origins share the same highest bcsId, all of them receive this count. |
 | `hdds.scm.replication.quasi.closed.stuck.other.origin.copies` | 2 | `SCM` | For quasi-closed stuck containers with multiple diverged origins, the number of replicas to maintain for each origin that does not have the highest block commit sequence ID (BCSID). These replicas are kept to preserve data integrity across diverged copies. |
 | `hdds.scm.replication.thread.interval` | 300s | `SCM`, `OZONE` | There is a replication monitor thread running inside SCM which takes care of replicating the containers in the cluster. This property is used to configure the interval in which that thread runs. |
@@ -568,7 +567,7 @@ This page provides a comprehensive overview of the configuration keys available
 | `ozone.om.snapshot.rename.allowed` | false | `OZONE`, `OM` | Allows the Ozone snapshot rename operation if set to true on the OM side. Blocks it otherwise. |
 | `ozone.om.snapshot.rocksdb.metrics.enabled` | false | `OZONE`, `OM` | Skip collecting RocksDBStore metrics for Snapshotted DB. |
 | `ozone.om.transport.class` | org.apache.hadoop.ozone.om.protocolPB.Hadoop3OmTransportFactory | `OM`, `MANAGEMENT` | Property to determine the transport protocol for the client to Ozone Manager channel. |
-| `ozone.om.unflushed.transaction.max.count` | 10000 | `OZONE`, `OM` | the unflushed transactions here are those requests that have been applied to OM state machine but not been flushed to OM rocksdb. when OM meets high concurrency-pressure and flushing is not fast enough, too many pending requests will be hold in memory and will lead to long GC of OM, which will slow down flushing further. there are some cases that flushing is slow, for example, 1 rocksdb is on a HDD, which has poor I/O [...]
+| `ozone.om.unflushed.transaction.max.count` | 10000 | `OZONE`, `OM` | the unflushed transactions here are those requests that have been applied to OM state machine but not been flushed to OM rocksdb. when OM meets high concurrency-pressure and flushing is not fast enough, too many pending requests will be hold in memory and will lead to long GC of OM, which will slow down flushing further. there are some cases that flushing is slow, for example, 1 rocksdb is on a HDD, which has poor IO  [...]
 | `ozone.om.upgrade.finalization.ratis.based.timeout` | 30s | `OM`, `UPGRADE` | Maximum time to wait for a slow follower to be finalized through a Ratis snapshot. This is an advanced config, and needs to be changed only under a special circumstance when the leader OM has purged the finalize request from its logs, and a follower OM was down during upgrade finalization. Default is 30s. |
 | `ozone.om.upgrade.quota.recalculate.enabled` | true | `OZONE`, `OM` | quota recalculation trigger when upgrade to the layout version QUOTA. while upgrade, re-calculation of quota used will block write operation to existing buckets till this operation is completed. |
 | `ozone.om.user.max.volume` | 1024 | `OM`, `MANAGEMENT` | The maximum number of volumes a user can have on a cluster.Increasing or decreasing this number has no real impact on ozone cluster. This is defined only for operational purposes. Only an administrator can create a volume, once a volume is created there are no restrictions on the number of buckets or keys inside each bucket a user can create. |


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@ozone.apache.org
For additional commands, e-mail: commits-help@ozone.apache.org