In most setups this is sufficient to heal the content after drive replacements. Setting `max_sleep` to a *lower* value and setting `max_io` to a *higher* value would make heal go faster.

If you have traditional spinning (hdd) drives, some applications with high concurrency might require MinIO cluster to be tuned such that to avoid random I/O on the drives. The way to convert high concurrent I/O into a sequential I/O is by reducing the number of concurrent operations allowed per cluster. This allows MinIO cluster to be operationally resilient to such workloads, while also making sure the drives are at optimal efficiency and responsive.

*Note*: Standalone MinIO is intended for early development and evaluation. For production clusters, deploy a [Distributed](https://min.io/docs/minio/container/operations/install-deploy-manage/deploy-minio-single-node-multi-drive.html) MinIO deployment.

Unit tests

```
λ make test
```

Verify different type of MinIO deployments work

```
λ make verify
```

Verify if healing and replacing a drive works

```
λ make verify-healing
```

	@(env bash $(PWD)/buildscripts/verify-healing-empty-erasure-set.sh)
	@(env bash $(PWD)/buildscripts/heal-inconsistent-versions.sh)

verify-healing-with-root-disks: ## verify healing root disks
	@echo "Verify healing with root drives"
	@GORACE=history_size=7 CGO_ENABLED=1 go build -race -tags kqueue -trimpath --ldflags "$(LDFLAGS)" -o $(PWD)/minio 1>/dev/null
	@(env bash $(PWD)/buildscripts/verify-healing-with-root-disks.sh)

drives.  Therefore, the number of drives you present must be a multiple of one of these numbers.  Each object is written to a single erasure-coding set.

Minio uses the largest possible EC set size which divides into the number of drives given. For example, *18 drives* are configured as *2 sets of 9 drives*, and *24 drives* are configured as *2 sets of 12 drives*.  This is true for scenarios when running MinIO as a standalone erasure coded deployment. In [distributed setup however node (affinity)...

two parity drives, 100 MiB file takes only approximately 114 MiB.

Below is a list of data/parity drives and corresponding _approximate_ storage space usage on a 16 drive MinIO deployment. The field _storage
usage ratio_ is simply the drive space used by the file after erasure-encoding, divided by actual file size.

| Total Drives (N) | Data Drives (D) | Parity Drives (P) | Storage Usage Ratio |

### 1.2 Host Multiple Tenants on Multiple Drives (Erasure Code)

Use the following commands to host 3 tenants on multiple drives:

```sh
minio server --address :9001 /disk{1...4}/data/tenant1
minio server --address :9002 /disk{1...4}/data/tenant2
minio server --address :9003 /disk{1...4}/data/tenant3
```

| `minio_system_drive_used_inodes`               | `gauge`   | Total used inodes on a drive                                       | `drive,set_index,drive_index,pool_index,server`     |
| `minio_system_drive_free_inodes`               | `gauge`   | Total free inodes on a drive                                       | `drive,set_index,drive_index,pool_index,server`     |

| `minio_node_drive_total_inodes`      | Total inodes on a drive.                                 |
| `minio_node_drive_used_inodes`       | Total inodes used on a drive.                            |
| `minio_node_drive_reads_per_sec`     | Reads per second on a drive.                             |
| `minio_node_drive_reads_kb_per_sec`  | Kilobytes read per second on a drive.                    |