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 <[email protected]>
AuthorDate: Mon Jul 13 22:12:18 2026 +0200
HDDS-15746. [Auto] Update configuration documentation (#487)
Co-authored-by: github-actions[bot]
<github-actions[bot]@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: [email protected]
For additional commands, e-mail: [email protected]
