minio/docs
1
0
Fork 0
mirror of https://github.com/minio/docs.git synced 2025-07-28 19:42:10 +03:00
Code Activity

Mc updates for multiple releases (#642)

Browse Source 
Updates `mc` reference docs for several releases of the MinIO Client.

- Adds missing flags to `mc admin trace`
- Updates `disk` -> `drive` throughout the docs, but not in all cases.
- Adds `--airgap flag` to `mc support profile` and `mc support perf`
commands.
- Updates the flags for `mc ilm add` command
- Adds `mc license unregister` command.
    
Closes #571
Closes #614
Closes #627
Closes #633
This commit is contained in:
Daryl White
2022-11-18 12:49:03 -06:00
committed by GitHub
parent 2f8c5a94f6
commit 0cd491c328
36 changed files with 291 additions and 140 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
source/administration/concepts.rst
View File

@ -54,7 +54,7 @@ Alternatively, you can configure MinIO to authenticate with one of several exter
How does MinIO secure data?
---------------------------
MinIO supports methods that encode objects while on disk (encryption-at-rest) and during transition from one location to another (encryption-in-transit, or "in flight").
MinIO supports methods that encode objects while on drive (encryption-at-rest) and during transition from one location to another (encryption-in-transit, or "in flight").
When enabled, MinIO utilizes :ref:`server-side encryption <minio-encryption-overview>` to write objects in an encrypted state.
To retrieve and read an encrypted object, the user must have appropriate access privileges and also provide the object's decryption key.

2
source/administration/minio-console.rst
View File

@ -123,7 +123,7 @@ and browser access on the MinIO Console port ``:9001``.
.. code-block:: shell
:class: copyable
minio server https://minio-{1...4}.example.net/mnt/disk-{1...4} \
minio server https://minio-{1...4}.example.net/mnt/drive-{1...4} \
--console-address ":9001"
Deployments behind network routing components which require static ports for

2
source/administration/object-management/object-versioning.rst
View File

@ -83,7 +83,7 @@ Versioning and Storage Capacity
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
MinIO does not perform incremental or differential-type versioning. For
mutation-heavy workloads, this may result in substantial disk usage by
mutation-heavy workloads, this may result in substantial drive usage by
older or aged object versions.
For example, consider a 1GB object containing log data. An application

2
source/administration/server-side-encryption/server-side-encryption-sse-c.rst
View File

@ -25,7 +25,7 @@ to regulatory and compliance requirements around secure locking and erasure.
The procedure on this page configures and enables Server-Side Encryption
with Client-Managed Keys (SSE-C). MinIO SSE-C supports client-driven
encryption of objects *before* writing the object to disk. Clients must
encryption of objects *before* writing the object to the drive. Clients must
specify the correct key to decrypt objects for read operations.
MinIO SSE-C is functionally compatible with Amazon

2
source/administration/server-side-encryption/server-side-encryption-sse-kms.rst
View File

@ -313,7 +313,7 @@ The table below describes each stage of the encryption process:
* - Encrypt the Object
- MinIO uses the |OEK| to encrypt the object *prior* to storing the
object to disk. MinIO then encrypts the |OEK| with the |KEK|.
object to the drive. MinIO then encrypts the |OEK| with the |KEK|.
MinIO stores the encrypted representation of the |OEK| and |DEK| as part
of the metadata.

2
source/administration/server-side-encryption/server-side-encryption-sse-s3.rst
View File

@ -290,7 +290,7 @@ The table below describes each stage of the encryption process:
* - Encrypt the Object
- MinIO uses the |OEK| to encrypt the object *prior* to storing the
object to disk. MinIO then encrypts the |OEK| with the |KEK|.
object to a drive. MinIO then encrypts the |OEK| with the |KEK|.
MinIO stores the encrypted representation of the |OEK| and |DEK| as part
of the metadata.

4
source/glossary.rst
View File

@ -87,7 +87,7 @@ Glossary
The object may or may not be encrypted on the origin or destination storage devices.
erasure coding
A technology that splits :term:`objects` into multiple shards and writes the shards to multiple, separate disks.
A technology that splits :term:`objects` into multiple shards and writes the shards to multiple, separate drives.
Depending on the :term:`topology` used, erasure coding allows for loss of drives or nodes within a MinIO deployment without losing read or write access.
@ -121,7 +121,7 @@ Glossary
Optionally, MinIO users can authenticate with credentials from a 3rd party identify provider (IDP), including either OpenID or LDAP providers.
JBOD
Initialism for "Just A Bunch of Disks".
Initialism for "Just A Bunch of Drives".
JBOD is a storage device enclosure that holds many hard drives.
These drives can combine into one logical drive unit.

26
source/includes/common-installation.rst
View File

@ -182,11 +182,11 @@ arrays with XFS-formatted disks for best performance.
Ensure all server drives for which you intend MinIO to use are of the same type (NVMe, SSD, or HDD) with identical capacity (e.g. ``12`` TB).
MinIO does not distinguish drive types and does not benefit from mixed storage types.
Additionally. MinIO limits the size used per disk to the smallest drive in the deployment.
For example, if the deployment has 15 10TB disks and 1 1TB disk, MinIO limits the per-disk capacity to 1TB.
Additionally. MinIO limits the size used per drive to the smallest drive in the deployment.
For example, if the deployment has 15 10TB drives and 1 1TB drive, MinIO limits the per-drive capacity to 1TB.
MinIO *requires* using expansion notation ``{x...y}`` to denote a sequential series of disks when creating the new |deployment|, where all nodes in the |deployment| have an identical set of mounted drives.
MinIO also requires that the ordering of physical disks remain constant across restarts, such that a given mount point always points to the same formatted disk.
MinIO *requires* using expansion notation ``{x...y}`` to denote a sequential series of drives when creating the new |deployment|, where all nodes in the |deployment| have an identical set of mounted drives.
MinIO also requires that the ordering of physical drives remain constant across restarts, such that a given mount point always points to the same formatted drive.
MinIO therefore **strongly recommends** using ``/etc/fstab`` or a similar file-based mount configuration to ensure that drive ordering cannot change after a reboot.
For example:
@ -205,8 +205,8 @@ For example:
LABEL=DISK3 /mnt/disk3 xfs defaults,noatime 0 2
LABEL=DISK4 /mnt/disk4 xfs defaults,noatime 0 2
You can then specify the entire range of disks using the expansion notation ``/mnt/disk{1...4}``.
If you want to use a specific subfolder on each disk, specify it as ``/mnt/disk{1...4}/minio``.
You can then specify the entire range of drives using the expansion notation ``/mnt/disk{1...4}``.
If you want to use a specific subfolder on each drive, specify it as ``/mnt/disk{1...4}/minio``.
MinIO **does not** support arbitrary migration of a drive with existing MinIO data to a new mount position, whether intentional or as the result of OS-level behavior.
@ -230,15 +230,15 @@ arrays with XFS-formatted disks for best performance.
Ensure all nodes in the |deployment| use the same type (NVMe, SSD, or HDD) of
drive with identical capacity (e.g. ``N`` TB) . MinIO does not distinguish drive
types and does not benefit from mixed storage types. Additionally. MinIO limits
the size used per disk to the smallest drive in the deployment. For example, if
the deployment has 15 10TB disks and 1 1TB disk, MinIO limits the per-disk
the size used per drive to the smallest drive in the deployment. For example, if
the deployment has 15 10TB drives and 1 1TB drive, MinIO limits the per-drive
capacity to 1TB.
MinIO *requires* using expansion notation ``{x...y}`` to denote a sequential
series of disks when creating the new |deployment|, where all nodes in the
series of drives when creating the new |deployment|, where all nodes in the
|deployment| have an identical set of mounted drives. MinIO also
requires that the ordering of physical disks remain constant across restarts,
such that a given mount point always points to the same formatted disk. MinIO
requires that the ordering of physical drives remain constant across restarts,
such that a given mount point always points to the same formatted drive. MinIO
therefore **strongly recommends** using ``/etc/fstab`` or a similar file-based
mount configuration to ensure that drive ordering cannot change after a reboot.
For example:
@ -258,8 +258,8 @@ For example:
LABEL=DISK3 /mnt/disk3 xfs defaults,noatime 0 2
LABEL=DISK4 /mnt/disk4 xfs defaults,noatime 0 2
You can then specify the entire range of disks using the expansion notation
``/mnt/disk{1...4}``. If you want to use a specific subfolder on each disk,
You can then specify the entire range of drives using the expansion notation
``/mnt/disk{1...4}``. If you want to use a specific subfolder on each drive,
specify it as ``/mnt/disk{1...4}/minio``.
MinIO **does not** support arbitrary migration of a drive with existing MinIO

4
source/includes/common-minio-sse.rst
View File

@ -18,7 +18,7 @@ a randomly generated initialization vector, and a context consisting of values
like the bucket and object name.
MinIO generates the KEK at the time of each cryptographic encryption or
decryption operation and *never* stores the KEK to disk.
decryption operation and *never* stores the KEK to a drive.
.. end-sse-kek
@ -26,7 +26,7 @@ decryption operation and *never* stores the KEK to disk.
MinIO generates a random 256-bit unique Object Encryption Key (OEK) and uses
that key to encrypt the object. MinIO never stores the plaintext representation
of the OEK on disk. The plaintext OEK resides in RAM during cryptographic
of the OEK on a drive. The plaintext OEK resides in RAM during cryptographic
operations.
.. end-sse-oek

2
source/includes/common/common-minio-kes.rst
View File

@ -93,7 +93,7 @@ Run the following commands in a terminal or shell to start the KES server as a f
The first command allows |KES| to use the `mlock <http://man7.org/linux/man-pages/man2/mlock.2.html>`__ system call without running as root.
``mlock`` ensures the OS does not write in-memory data to disk (swap memory) and mitigates the risk of cryptographic operations being written to unsecured disk at any time.
``mlock`` ensures the OS does not write in-memory data to a drive (swap memory) and mitigates the risk of cryptographic operations being written to unsecured drive at any time.
KES 0.21.0 and later automatically detect and enable ``mlock`` if supported by the host OS.
Versions 0.20.0 and earlier required specifying the ``--mlock`` argument to KES.

2
source/includes/k8s/deploy-tenant-requirements.rst
View File

@ -17,7 +17,7 @@
persistentVolumeReclaimPolicy: Retain
storage-class: <STORAGE-CLASS>
local:
path: <PATH-TO-DISK>
path: <PATH-TO-DRIVE>
nodeAffinity:
required:
nodeSelectorTerms:

4
source/includes/linux/common-installation.rst
View File

@ -206,8 +206,8 @@ require root (``sudo``) permissions.
useradd -M -r -g minio-user minio-user
chown minio-user:minio-user /mnt/disk1 /mnt/disk2 /mnt/disk3 /mnt/disk4
The specified disk paths are provided as an example. Change them to match
the path to those disks intended for use by MinIO.
The specified drive paths are provided as an example. Change them to match
the path to those drives intended for use by MinIO.
Alternatively, change the ``User`` and ``Group`` values to another user and
group on the system host with the necessary access and permissions.

6
source/integrations/disaggregated-spark-and-hadoop-hive-with-minio.md
View File

@ -52,8 +52,8 @@ mapreduce.job.reduce.slowstart.completedmaps=0.99 # 99% map, then reduce
mapreduce.reduce.shuffle.input.buffer.percent=0.9 # Min % buffer in RAM
mapreduce.reduce.shuffle.merge.percent=0.9 # Minimum % merges in RAM
mapreduce.reduce.speculative=false # Disable speculation for reducing
mapreduce.task.io.sort.factor=999 # Threshold before writing to disk
mapreduce.task.sort.spill.percent=0.9 # Minimum % before spilling to disk
mapreduce.task.io.sort.factor=999 # Threshold before writing to drive
mapreduce.task.sort.spill.percent=0.9 # Minimum % before spilling to drive
```
S3A is the connector to use S3 and other S3-compatible object stores such as MinIO. MapReduce workloads typically interact with object stores in the same way they do with HDFS. These workloads rely on HDFS atomic rename functionality to complete writing data to the datastore. Object storage operations are atomic by nature and they do not require/implement rename API. The default S3A committer emulates renames through copy and delete APIs. This interaction pattern causes significant loss of performance because of the write amplification. _Netflix_, for example, developed two new staging committers - the Directory staging committer and the Partitioned staging committer - to take full advantage of native object storage operations. These committers do not require rename operation. The two staging committers were evaluated, along with another new addition called the Magic committer for benchmarking.
@ -83,7 +83,7 @@ fs.s3a.impl=org.apache.hadoop.fs.s3a.S3AFileSystem
fs.s3a.committer.threads=2048 # Number of threads writing to MinIO
fs.s3a.connection.maximum=8192 # Maximum number of concurrent conns
fs.s3a.fast.upload.active.blocks=2048 # Number of parallel uploads
fs.s3a.fast.upload.buffer=disk # Use disk as the buffer for uploads
fs.s3a.fast.upload.buffer=disk # Use drive as the buffer for uploads
fs.s3a.fast.upload=true # Turn on fast upload mode
fs.s3a.max.total.tasks=2048 # Maximum number of parallel tasks
fs.s3a.multipart.size=512M # Size of each multipart chunk

18
source/operations/checklists/hardware.rst
View File

@ -251,12 +251,12 @@ HDD - Warm
- Low
- Cold/Archival
Use the same type of disk (NVME, SSD, HDD) with the same capacity across all nodes in a MinIO deployment.
Use the same type of drive (NVME, SSD, HDD) with the same capacity across all nodes in a MinIO deployment.
MinIO does not distinguish drive types when using the underlying storage and does not benefit from mixed storage types.
Use the same capacity of disk across all nodes in the MinIO :ref:`server pool <minio-intro-server-pool>`.
MinIO limits the maximum usable size per disk to the smallest size in the deployment.
For example, if a deployment has 15 10TB disks and 1 1TB disk, MinIO limits the per-disk capacity to 1TB.
Use the same capacity of drive across all nodes in the MinIO :ref:`server pool <minio-intro-server-pool>`.
MinIO limits the maximum usable size per drive to the smallest size in the deployment.
For example, if a deployment has 15 10TB drives and 1 1TB drive, MinIO limits the per-drive capacity to 1TB.
Recommended Hardware Tests
--------------------------
@ -324,7 +324,7 @@ Record the results for later reference.
#. Test the drive's performance during write operations
This tests checks a drive's ability to write new data (uncached) to disk by creating a specified number of blocks at up to a certain number of bytes at a time to mimic how a drive would function with writing uncached data.
This tests checks a drive's ability to write new data (uncached) to the drive by creating a specified number of blocks at up to a certain number of bytes at a time to mimic how a drive would function with writing uncached data.
This allows you to see the actual drive performance with consistent file I/O.
.. code-block::
@ -332,7 +332,7 @@ Record the results for later reference.
dd if=/dev/zero of=/mnt/driveN/testfile bs=128k count=80000 oflag=direct conv=fdatasync > dd-write-drive1.txt
Replace ``driveN`` with the path for the disk you are testing.
Replace ``driveN`` with the path for the drive you are testing.
.. list-table::
:widths: auto
@ -364,7 +364,7 @@ Record the results for later reference.
dd if=/mnt/driveN/testfile of=/dev/null bs=128k iflag=direct > dd-read-drive1.txt
Replace ``driveN`` with the path for the disk you are testing.
Replace ``driveN`` with the path for the drive you are testing.
.. list-table::
:widths: auto
@ -429,6 +429,6 @@ Document the performance numbers for each server in your deployment.
* - ``-I``
- Direct-IO modern
* - ``-t N``
- Number of threads (:math:`numberOfDisks * 16`)
- Number of threads (:math:`numberOfDrives * 16`)
* - ``-F <>``
- list of files (the above command tests with 16 files per disk)
- list of files (the above command tests with 16 files per drive)

4
source/operations/concepts.rst
View File

@ -176,7 +176,7 @@ Some common reasons for bit rot include:
- ageing drives
- current spikes
- bugs in disk firmware
- bugs in drive firmware
- phantom writes
- misdirected reads/writes
- driver errors
@ -210,7 +210,7 @@ MinIO Writes Data Protection at the Object Level with Parity
A MinIO deployment with multiple drives divides the available drives into data drives and parity drives.
MinIO Erasure Coding adds additional hashing information about the contents of an object to the parity drives when writing an object.
MinIO uses the parity information to confirm the integrity of an object and, if necessary, to restore a lost, missing, or corrupted object shard on a given disk or set of disks.
MinIO uses the parity information to confirm the integrity of an object and, if necessary, to restore a lost, missing, or corrupted object shard on a given drive or set of drives.
MinIO can tolerate losing up to the total number of drives equal to the number of parity devices available in the erasure set while still providing full access to an object.

6
source/operations/concepts/erasure-coding.rst
View File

@ -193,10 +193,10 @@ Bit Rot Protection
.. TODO- ReWrite w/ more detail.
Silent data corruption or bit rot is a serious problem faced by disk drives resulting in data getting corrupted without the user’s knowledge.
The corruption of data occurs when the electrical charge on a portion of the disk disperses or changes with no notification to or input from the user.
Silent data corruption or bit rot is a serious problem faced by data drives resulting in data getting corrupted without the user’s knowledge.
The corruption of data occurs when the electrical charge on a portion of the drive disperses or changes with no notification to or input from the user.
Many events can lead to such a silent corruption of stored data.
For example, ageing drives, current spikes, bugs in disk firmware, phantom writes, misdirected reads/writes, driver errors, accidental overwrites, or a random cosmic ray can each lead to a bit change.
For example, ageing drives, current spikes, bugs in drive firmware, phantom writes, misdirected reads/writes, driver errors, accidental overwrites, or a random cosmic ray can each lead to a bit change.
Whatever the cause, the result is the same - compromised data.
MinIO’s optimized implementation of the :minio-git:`HighwayHash algorithm <highwayhash/blob/master/README.md>` ensures that it captures and heals corrupted objects on the fly.

4
source/operations/data-recovery.rst
View File

@ -11,7 +11,7 @@ Recover after Hardware Failure
:depth: 1
Distributed MinIO deployments rely on :ref:`Erasure Coding
<minio-erasure-coding>` to provide built-in tolerance for multiple disk or node
<minio-erasure-coding>` to provide built-in tolerance for multiple drive or node
failures. Depending on the deployment topology and the selected erasure code
parity, MinIO can tolerate the loss of up to half the drives or nodes in the
deployment while maintaining read access ("read quorum") to objects.
@ -43,7 +43,7 @@ allow for a more reasonable replacement timeframe, while "critical" failure
rates (multiple drives or nodes) may require a faster response.
For nodes with one or more drives that are either partially failed or operating
in a degraded state (increasing disk errors, SMART warnings, timeouts in MinIO
in a degraded state (increasing drive errors, SMART warnings, timeouts in MinIO
logs, etc.), you can safely unmount the drive *if* the cluster has sufficient
remaining healthy drives to maintain
:ref:`read and write quorum <minio-ec-parity>`. Missing drives are less

24
source/operations/data-recovery/recover-after-drive-failure.rst
View File

@ -54,7 +54,7 @@ the failed drive.
.. code-block:: shell
mkfs.xfs /dev/sdb -L DISK1
mkfs.xfs /dev/sdb -L DRIVE1
MinIO **strongly recommends** using label-based mounting to ensure consistent
drive order that persists through system restarts.
@ -63,13 +63,13 @@ drive order that persists through system restarts.
------------------------------
Review the ``/etc/fstab`` file and update as needed such that the entry for
the failed disk points to the newly formatted replacement.
the failed drive points to the newly formatted replacement.
- If using label-based disk assignment, ensure that each label points to the
correct newly formatted disk.
- If using label-based drive assignment, ensure that each label points to the
correct newly formatted drive.
- If using UUID-based disk assignment, update the UUID for each point based on
the newly formatted disk. You can use ``lsblk`` to view disk UUIDs.
- If using UUID-based drive assignment, update the UUID for each point based on
the newly formatted drive. You can use ``lsblk`` to view drive UUIDs.
For example, consider
@ -78,14 +78,14 @@ For example, consider
$ cat /etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>
LABEL=DISK1 /mnt/disk1 xfs defaults,noatime 0 2
LABEL=DISK2 /mnt/disk2 xfs defaults,noatime 0 2
LABEL=DISK3 /mnt/disk3 xfs defaults,noatime 0 2
LABEL=DISK4 /mnt/disk4 xfs defaults,noatime 0 2
LABEL=DRIVE1 /mnt/drive1 xfs defaults,noatime 0 2
LABEL=DRIVE2 /mnt/drive2 xfs defaults,noatime 0 2
LABEL=DRIVE3 /mnt/drive3 xfs defaults,noatime 0 2
LABEL=DRIVE4 /mnt/drive4 xfs defaults,noatime 0 2
Given the previous example command, no changes are required to
``fstab`` since the replacement disk at ``/mnt/disk1`` uses the same
label ``DISK1`` as the failed disk.
``fstab`` since the replacement drive at ``/mnt/drive1`` uses the same
label ``DRIVE1`` as the failed drive.
4) Remount the Replaced Drive(s)
--------------------------------

4
source/operations/install-deploy-manage/deploy-minio-multi-node-multi-drive.rst
View File

@ -94,7 +94,7 @@ Local JBOD Storage with Sequential Mounts
:class: note
MinIO's strict **read-after-write** and **list-after-write** consistency
model requires local disk filesystems.
model requires local drive filesystems.
MinIO cannot provide consistency guarantees if the underlying storage
volumes are NFS or a similar network-attached storage volume.
@ -252,7 +252,7 @@ The following examples assumes that:
minio1.example.com minio3.example.com
minio2.example.com minio4.example.com
- All hosts have four locally-attached disks with sequential mount-points:
- All hosts have four locally-attached drives with sequential mount-points:
.. code-block:: shell

2
source/operations/install-deploy-manage/deploy-minio-single-node-multi-drive.rst
View File

@ -39,7 +39,7 @@ Local JBOD Storage with Sequential Mounts
:class: note
MinIO's strict **read-after-write** and **list-after-write** consistency
model requires local disk filesystems.
model requires local drive filesystems.
MinIO cannot provide consistency guarantees if the underlying storage
volumes are NFS or a similar network-attached storage volume.

2
source/operations/install-deploy-manage/deploy-minio-single-node-single-drive.rst
View File

@ -77,7 +77,7 @@ The following procedure deploys MinIO consisting of a single MinIO server and a
:class: note
MinIO's strict **read-after-write** and **list-after-write** consistency
model requires local disk filesystems (``xfs``, ``ext4``, etc.).
model requires local drive filesystems (``xfs``, ``ext4``, etc.).
MinIO cannot provide consistency guarantees if the underlying storage
volumes are NFS or a similar network-attached storage volume.

8
source/operations/install-deploy-manage/expand-minio-deployment.rst
View File

@ -21,7 +21,7 @@ MinIO supports expanding an existing distributed deployment by adding a new
:ref:`Server Pool <minio-intro-server-pool>`. Each Pool expands the total
available storage capacity of the cluster while maintaining the overall
:ref:`availability <minio-erasure-coding>` of the cluster. Each Pool is its
own failure domain, where the loss of one or more disks or nodes in that pool
own failure domain, where the loss of one or more drives or nodes in that pool
does not effect the availability of other pools in the deployment.
The procedure on this page expands an existing
@ -104,7 +104,7 @@ Local JBOD Storage with Sequential Mounts
:class: note
MinIO's strict **read-after-write** and **list-after-write** consistency
model requires local disk filesystems (``xfs``, ``ext4``, etc.).
model requires local drive filesystems (``xfs``, ``ext4``, etc.).
MinIO cannot provide consistency guarantees if the underlying storage
volumes are NFS or a similar network-attached storage volume.
@ -158,7 +158,7 @@ MinIO calculates the probability of a write operation to each of the pools as:
- Pool B: 20% chance (:math:`2TiB / 10TiB`)
- Pool C: 50% chance (:math:`5TiB / 10TiB`)
In addition to the free space calculation, if a write option (with parity) would bring a disk
In addition to the free space calculation, if a write option (with parity) would bring a drive
usage above 99% or a known free inode count below 1000, MinIO does not write to the pool.
If desired, you can manually initiate a rebalance procedure with :mc:`mc admin rebalance`.
@ -321,7 +321,7 @@ The following examples assumes that:
minio7.example.com minio11.example.com
minio8.example.com minio12.example.com
- All hosts have eight locally-attached disks with sequential mount-points:
- All hosts have eight locally-attached drives with sequential mount-points:
.. code-block:: shell

2
source/operations/install-deploy-manage/expand-minio-tenant.rst
View File

@ -38,7 +38,7 @@ Locally Attached Drives
~~~~~~~~~~~~~~~~~~~~~~~
MinIO *strongly recommends* using locally attached drives on each node intended to support the new tenant pool to ensure optimal performance.
MinIO’s strict read-after-write and list-after-write consistency model requires local disk filesystems (xfs, ext4, etc.).
MinIO’s strict read-after-write and list-after-write consistency model requires local drive filesystems (xfs, ext4, etc.).
MinIO automatically generates :kube-docs:`Persistent Volume Claims (PVC) <concepts/storage/persistent-volumes/#persistentvolumeclaims>` as part of deploying a MinIO Tenant.
The Operator generates one PVC for each volume in the new pool.

2
source/operations/monitoring/healthcheck-probe.rst
View File

@ -70,7 +70,7 @@ metrics to detect potential issues or errors on the MinIO cluster:
MinIO nodes are offline.
- :metric:`minio_node_disk_free_bytes` to alert if the cluster is running
low on free disk space.
low on free drive space.
Cluster Read Quorum
--------------------

10
source/operations/monitoring/metrics-and-alerts.rst
View File

@ -195,20 +195,20 @@ Lifecycle Management Metrics
Total number of active :ref:`object expiration <minio-lifecycle-management-expiration>` tasks
Node and Disk Health Metrics
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Node and Drive Health Metrics
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. metric:: minio_cluster_disk_online_total
The total number of disks online
The total number of drives online
.. metric:: minio_cluster_disk_offline_total
The total number of disks offline
The total number of drives offline
.. metric:: minio_cluster_disk_total
The total number of disks
The total number of drives
.. metric:: minio_cluster_nodes_offline_total

2
source/operations/monitoring/minio-logging.rst
View File

@ -233,7 +233,7 @@ MinIO audit logs resemble the following JSON document:
- The :ref:`erasure set <minio-ec-erasure-set>` on which the object
operation was performed.
- The list of disks in the erasure set which participated in the
- The list of drives in the erasure set which participated in the
object operation.
.. code-block:: json

4
source/reference/minio-mc-admin/mc-admin-heal.rst
View File

@ -21,8 +21,8 @@ corrupted and heals those objects.
.. end-mc-admin-heal-desc
:mc-cmd:`mc admin heal` is resource intensive and typically not required even
after disk failures or corruption events. Instead, MinIO automatically heals
objects damaged by silent bit rot corruption, disk failure, or other issues on
after drive failures or corruption events. Instead, MinIO automatically heals
objects damaged by silent bit rot corruption, drive failure, or other issues on
POST/GET. MinIO also performs periodic background object healing.
.. admonition:: Use ``mc admin`` on MinIO Deployments Only

89
source/reference/minio-mc-admin/mc-admin-trace.rst
View File

@ -26,18 +26,45 @@ The :mc-cmd:`mc admin trace` command displays API operations occurring on the ta
:start-after: start-minio-only
:end-before: end-minio-only
Example
-------
Examples
--------
Monitor All API operations
~~~~~~~~~~~~~~~~~~~~~~~~~~
Use :mc-cmd:`mc admin trace` to monitor API operations on a MinIO deployment:
.. code-block:: shell
:class: copyable
mc admin trace ALIAS
mc admin trace -a ALIAS
- Replace :mc-cmd:`ALIAS <mc admin trace TARGET>` with the
:mc-cmd:`alias <mc alias>` of the MinIO deployment.
- Replace :mc-cmd:`ALIAS <mc admin trace TARGET>` with the :mc-cmd:`alias <mc alias>` of the MinIO deployment.
See Calls that Return 503 Errors
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Use :mc-cmd:`mc admin trace` to monitor API operations that return a service unavailable 503 error:
.. code-block:: shell
:class: copyable
mc admin trace -v --status-code 503 ALIAS
- Replace :mc-cmd:`ALIAS <mc admin trace TARGET>` with the :mc-cmd:`alias <mc alias>` of the MinIO deployment.
See Console Trace for a Path
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Use :mc-cmd:`mc admin trace` to monitory activity for a specific path:
.. code-block:: shell
:class: copyable
mc admin trace --path my-bucket/my-prefix/* ALIAS
- Replace :mc-cmd:`ALIAS <mc admin trace TARGET>` with the :mc-cmd:`alias <mc alias>` of the MinIO deployment.
- Replace ``my-bucket/my-prefix/*`` with the bucket, prefix, and object name or wildcard you wish to trace.
Syntax
------
@ -57,16 +84,60 @@ Syntax
.. mc-cmd:: --all, a
Returns all traffic on the MinIO deployment, including internode traffic between MinIO servers.
Returns all traffic on the MinIO deployment, including internode traffic
between MinIO servers.
.. mc-cmd:: --call
Traces only matching call types.
For example, the following command only traces calls of the type ``scanner``.
.. code-block:: shell
mc admin trace --call scanner TARGET
Valid call types include:
- ``s3``
- ``internal``
- ``storage``
- ``os``
- ``scanner``
- ``decommission``
- ``healing``
.. mc-cmd:: --verbose
Returns verbose output.
.. mc-cmd:: --errors, e
Returns failed API operations only.
.. mc-cmd:: --response-threshold
Takes a time string as a value, such as ``5ms``.
Returns only calls with a response time greater than the supplied threshold.
.. mc-cmd:: --status-code
Returns calls of the specified HTTP status code.
.. mc-cmd:: --method
Returns call of the specified HTTP method.
.. mc-cmd:: --funcname
Returns calls for the entered function name.
.. mc-cmd:: --path
Returns calls for the specified path.
.. mc-cmd:: --node
Returns calls for the specified server.
.. mc-cmd:: --request-header
Returns calls matching the supplied request header.

7
source/reference/minio-mc.rst
View File

@ -249,8 +249,10 @@ The following table lists :mc-cmd:`mc` commands:
* - | :mc:`mc license register`
| :mc:`mc license info`
| :mc:`mc license update`
- The ``mc license`` command registers clusters with |SUBNET|, displays information about the cluster's current license, or updates the license key for a cluster.
| :mc:`mc license update`
| :mc:`mc license unregister`
- The ``mc license`` commands work with cluster registration for |SUBNET|.
Use the commands to register a deployment, unregister a deployment, display information about the cluster's current license, or update the license key for a cluster.
* - :mc:`mc ls`
- .. include:: /reference/minio-mc/mc-ls.rst
@ -509,6 +511,7 @@ All :ref:`commands <minio-mc-commands>` support the following global options:
/reference/minio-mc/mc-legalhold-clear
/reference/minio-mc/mc-license-info
/reference/minio-mc/mc-license-register
/reference/minio-mc/mc-license-unregister
/reference/minio-mc/mc-license-update
/reference/minio-mc/mc-ls
/reference/minio-mc/mc-mb

86
source/reference/minio-mc/mc-ilm-add.rst
View File

@ -32,13 +32,13 @@ The command supports adding both :ref:`Transition (Tiering) <minio-lifecycle-man
.. code-block:: shell
:class: copyable
mc ilm add --expiry-days 90 --noncurrentversion-expiry-days 30 mydata/myminio
mc ilm add --expire-days 90 --noncurrent-expire-days 30 mydata/myminio
mc ilm add --expired-object-delete-marker mydata/myminio
mc ilm add --expire-delete-marker mydata/myminio
mc ilm add --transition-days 30 --tier "COLDTIER" mydata/myminio
mc ilm add --noncurrentversion-transition-days 7 --noncurrent-version-transition-tier "COLDTIER"
mc ilm add --noncurrent-transition-days 7 --noncurrent-transition-tier "COLDTIER"
The configured rules have the following effect:
@ -55,18 +55,18 @@ The command supports adding both :ref:`Transition (Tiering) <minio-lifecycle-man
.. code-block:: shell
:class: copyable
mc [GLOBALFLAGS] ilm add \
--expiry-days "integer" \
[--prefix string] \
[--tags string] \
[--transition-days "string"] \
[--tier "string"] \
[--expired-object-delete-marker] \
[--noncurrentversion-expiration-days "integer"] \
[--noncurrentversion-transition-days "integer"] \
[--noncurrentversion-tier "string"] \
[--newer-noncurrentversions-expiration "integer"] \
[--newer-noncurrentversions-transition "integer"] \
mc [GLOBALFLAGS] ilm add \
[--prefix string] \
[--tags string] \
--expire-days "integer" \
[--expire-delete-marker] \
[--transition-days "string"] \
[--transition-tier "string"] \
[--noncurrent-expire-days "integer"] \
[--noncurrent-expire-newer "integer"] \
[--noncurrent-transition-days "integer"] \
[--noncurrent-transition-newer "integer"] \
[--noncurrent-transition-tier "string"] \
ALIAS
.. include:: /includes/common-minio-mc.rst
@ -100,7 +100,16 @@ Parameters
The command creates a rule that expires objects in the ``mydata`` bucket of the ``myminio`` ALIAS after 90 days for any object with the ``meetingnotes/`` prefix.
.. mc-cmd:: --expiry-days
.. mc-cmd:: --tags
:optional:
One or more ampersand ``&``-delimited key-value pairs describing the object tags to use for filtering objects to which the lifecycle configuration rule applies.
This option is mutually exclusive with the following option:
- :mc-cmd:`~mc ilm add --expire-delete-marker`
.. mc-cmd:: --expire-days
:required:
The number of days to retain an object after being created.
@ -108,7 +117,7 @@ Parameters
Specify the number of days as an integer, e.g. ``30`` for 30 days.
For versioned buckets, the expiry rule applies only to the *current* object version.
Use the :mc-cmd:`~mc ilm add --noncurrentversion-expiration-days` option to apply expiration behavior to noncurrent object versions.
Use the :mc-cmd:`~mc ilm add --noncurrent-expire-days` option to apply expiration behavior to noncurrent object versions.
MinIO uses a scanner process to check objects against all configured lifecycle management rules.
Slow scanning due to high IO workloads or limited system resources may delay application of lifecycle management rules.
@ -116,11 +125,11 @@ Parameters
Mutually exclusive with the following options:
- :mc-cmd:`~mc ilm add --expired-object-delete-marker`
- :mc-cmd:`~mc ilm add --expire-delete-marker`
For more complete documentation on object expiration, see :ref:`minio-lifecycle-management-expiration`.
.. mc-cmd:: --expired-object-delete-marker
.. mc-cmd:: --expire-delete-marker
:optional:
Specify this option to direct MinIO to remove delete markers for objects with no remaining object versions.
@ -129,7 +138,7 @@ Parameters
This option is mutually exclusive with the following option:
- :mc-cmd:`~mc ilm add --tags`
- :mc-cmd:`~mc ilm add --expiry-days`
- :mc-cmd:`~mc ilm add --expire-days`
MinIO uses a scanner process to check objects against all configured lifecycle management rules.
Slow scanning due to high IO workloads or limited system resources may delay application of lifecycle management rules.
@ -142,13 +151,13 @@ Parameters
:optional:
The number of calendar days from object creation after which MinIO marks an object as eligible for transition.
MinIO transitions the object to the configured remote tier specified to the :mc-cmd:`~mc ilm add --tier`.
MinIO transitions the object to the configured remote tier specified to the :mc-cmd:`~mc ilm add --transition-tier`.
Specify the number of days as an integer, e.g. ``30`` for 30 days.
For versioned buckets, the transition rule applies only to the *current* object version.
Use the :mc-cmd:`~mc ilm add --noncurrentversion-transition-days` option to apply transition behavior to noncurrent object versions.
Use the :mc-cmd:`~mc ilm add --noncurrent-transition-days` option to apply transition behavior to noncurrent object versions.
Requires specifying :mc-cmd:`~mc ilm add --tier`.
Requires specifying :mc-cmd:`~mc ilm add --transition-tier`.
MinIO uses a scanner process to check objects against all configured lifecycle management rules.
Slow scanning due to high IO workloads or limited system resources may delay application of lifecycle management rules.
@ -156,7 +165,7 @@ Parameters
For more complete documentation on object transition, see :ref:`minio-lifecycle-management-tiering`.
.. mc-cmd:: --tier
.. mc-cmd:: --transition-tier
:optional:
The remote tier to which MinIO :ref:`transition objects <minio-lifecycle-management-tiering>`.
@ -164,16 +173,7 @@ Parameters
Required if specifying :mc-cmd:`~mc ilm add --transition-days`.
.. mc-cmd:: --tags
:optional:
One or more ampersand ``&``-delimited key-value pairs describing the object tags to use for filtering objects to which the lifecycle configuration rule applies.
This option is mutually exclusive with the following option:
- :mc-cmd:`~mc ilm add --expired-object-delete-marker`
.. mc-cmd:: --noncurrentversion-expiration-days
.. mc-cmd:: --noncurrent-expire-days
:optional:
The number of days to retain an object version after becoming *non-current* (i.e. a different version of that object is now the `HEAD`).
@ -185,14 +185,14 @@ Parameters
Slow scanning due to high IO workloads or limited system resources may delay application of lifecycle management rules.
See :ref:`minio-lifecycle-management-scanner` for more information.
.. mc-cmd:: --noncurrentversion-transition-days
.. mc-cmd:: --noncurrent-transition-days
:optional:
The number of days an object has been non-current (i.e. replaced by a newer version of that same object) after which MinIO marks the object version as eligible for transition.
MinIO transitions the object to the configured remote tier specified to the :mc-cmd:`~mc ilm add --tier` once the system host datetime passes that calendar date.
The number of days an object has been non-current (i.e. replaced by a newer version of that same object) after which MinIO marks the object version as eligible for transition.
MinIO transitions the object to the configured remote tier specified to the :mc-cmd:`~mc ilm add --transition-tier` once the system host datetime passes that calendar date.
This option has no effect on non-versioned buckets.
Requires specifying :mc-cmd:`~mc ilm add --noncurrentversion-tier`.
Requires specifying :mc-cmd:`~mc ilm add --noncurrent-transition-tier`.
This option has the same behavior as the S3 ``NoncurrentVersionTransition`` action.
@ -200,13 +200,13 @@ Parameters
Slow scanning due to high IO workloads or limited system resources may delay application of lifecycle management rules.
See :ref:`minio-lifecycle-management-scanner` for more information.
.. mc-cmd:: --noncurrentversion-tier
.. mc-cmd:: --noncurrent-transition-tier
:optional:
The remote tier to which MinIO :ref:`transitions noncurrent objects versions <minio-lifecycle-management-tiering>`.
Specify a remote tier created by :mc:`mc admin tier`.
.. mc-cmd:: --newer-noncurrentversions-expiration
.. mc-cmd:: --noncurrent-expire-newer
:optional:
The maximum number of non-current object versions to retain, ordered from newest to oldest.
@ -214,7 +214,7 @@ Parameters
Use this flag to retain a certain number of past versions of a file in a first in, first out fashion.
After retaining the maximum number of non-current versions, MinIO marks any remaining older non-current object versions as eligible for expiration.
The following table lists a number of object versions and their expiration eligibility based on ``--newer-noncurrentversions-expiration 3``:
The following table lists a number of object versions and their expiration eligibility based on ``--noncurrent-expire-newer 3``:
.. list-table::
:widths: 50 50
@ -244,7 +244,7 @@ Parameters
Slow scanning due to high IO workloads or limited system resources may delay application of lifecycle management rules.
See :ref:`minio-lifecycle-management-scanner` for more information.
.. mc-cmd:: --newer-noncurrentversions-transition
.. mc-cmd:: --noncurrent-transition-newer
:optional:
The maximum number of non-current object versions to retain on the current tier.
@ -254,7 +254,7 @@ Parameters
If not specified, all non-current object versions transition to the different tier.
The following table lists a number of object versions and their transition eligibility based on ``--newer-noncurrentversions-transition 3``:
The following table lists a number of object versions and their transition eligibility based on ``--noncurrent-transition-newer 3``:
.. list-table::
:widths: 50 50

58
source/reference/minio-mc/mc-license-unregister.rst Normal file
View File

@ -0,0 +1,58 @@
=========================
``mc license unregister``
=========================
.. default-domain:: minio
.. contents:: Table of Contents
:local:
:depth: 1
.. mc:: mc license unregister
Description
-----------
The :mc-cmd:`mc license unregister` command disconnects your deployment from your |SUBNET| account.
After unregistering, you can no longer use the :mc:`mc support` commands.
Examples
--------
Unregister a Deployment Using the Deployment's Name
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Remove the registration of the MinIO deployment at alias ``minio1`` from SUBNET.
.. code-block:: shell
:class: copyable
mc license unregister minio1
Syntax
------
The command has the following syntax:
.. code-block:: shell
mc [GLOBALFLAGS] license unregister ALIAS
Parameters
~~~~~~~~~~
.. mc-cmd:: ALIAS
:required:
The :ref:`alias <alias>` of the MinIO deployment.
Global Flags
~~~~~~~~~~~~
.. include:: /includes/common-minio-mc.rst
:start-after: start-minio-mc-globals
:end-before: end-minio-mc-globals

1
source/reference/minio-mc/mc-support-diag.rst
View File

@ -8,6 +8,7 @@
:local:
:depth: 1
.. mc:: mc support
.. mc:: mc support diag
.. include:: /includes/common-mc-support.rst

14
source/reference/minio-mc/mc-support-perf.rst
View File

@ -110,6 +110,7 @@ Measure the read/write speed of the drives in a cluster.
[--filesize] \
[--blocksize] \
[--serial] \
[--airgap] \
ALIAS
.. mc-cmd:: object
@ -124,12 +125,13 @@ Measure the S3 peformance of reading and writing objects in a cluster.
[--size] \
[--concurrent] \
[--verbose, -v] \
[--airgap] \
ALIAS
.. mc-cmd:: net
:fullpath:
Measure the network throughput of all nodes in a cluster.
Measure the network throughput of all nodes in a cluster.
.. code-block:: shell
@ -137,6 +139,7 @@ Measure the network throughput of all nodes in a cluster.
[--concurrent] \
[--verbose, -v] \
[--serial] \
[--airgap] \
ALIAS
Parameters
@ -153,9 +156,16 @@ Parameters
Use ``--duration <value>`` where ``<value>`` is a number and a unit of ``s`` for seconds, ``m`` for minutes.
.. mc-cmd:: --size
.. mc-cmd:: --airgap
:optional:
Use in environments without network access to SUBNET (for example, airgapped, firewalled, or similar configuration).
If the deployment is airgapped, but the local device where you are using the :ref:`minio client <minio-client>` has network access, you do not need to use the ``--airgap`` flag.
.. mc-cmd:: --size
:optional:
Applies to the :mc-cmd:`~mc support perf object` command.
Specify the size of the object to use for upload and download performance test.

16
source/reference/minio-mc/mc-support-profile.rst
View File

@ -68,10 +68,11 @@ The :mc:`mc support profile` command has the following syntax:
.. code-block:: shell
mc [GLOBALFLAGS] support profile \
COMMAND \
[--type] \
[--duration]
mc [GLOBALFLAGS] support profile \
COMMAND \
[--type] \
[--airgap] \
[--duration] \
ALIAS
Parameters
@ -106,6 +107,13 @@ Parameters
If not specified, the command collects data for CPU, memory, block, mutex, threads, and goroutines.
.. mc-cmd:: --airgap
:optional:
Use in environments without network access to SUBNET (for example, airgapped, firewalled, or similar configuration).
If the deployment is airgapped, but the local device where you are using the :ref:`minio client <minio-client>` has network access, you do not need to use the ``--airgap`` flag.
.. mc-cmd:: ALIAS
:required:

6
source/reference/minio-mc/mc-support-top-disk.rst
View File

@ -15,7 +15,7 @@ Syntax
.. start-mc-support-top-disk-desc
The :mc:`mc support top disk` command displays current disk statistics.
The :mc:`mc support top disk` command displays current drive statistics.
.. end-mc-support-top-disk-desc
@ -56,9 +56,9 @@ Parameters
.. mc-cmd:: --count, -c
:optional:
Display statistics for up to the entered number of disks.
Display statistics for up to the entered number of drives.
If no entry is made, the command returns statistics for up to 10 disks.
If no entry is made, the command returns statistics for up to 10 drives.
Global Flags
~~~~~~~~~~~~

2
source/reference/minio-server/minio-server.rst
View File

@ -116,7 +116,7 @@ The command accepts the following arguments:
.. important::
MinIO recommends locally-attached drives, where the
:mc-cmd:`~minio server DIRECTORIES` path points to each disk on the
:mc-cmd:`~minio server DIRECTORIES` path points to each drive on the
host machine. MinIO recommends *against* using network-attached
storage, as network latency reduces performance of those drives
compared to locally-attached storage.