minio/docs
1
0
Fork 0
mirror of https://github.com/minio/docs.git synced 2025-08-09 13:02:53 +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

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.