Multiple SERVER Releases (#1141)

MinIO SERVER RELEASE.2024-01-05T22-17-24Z - added new metrics to
github.com/minio/minio for later sync

MinIO SERVER RELEASE.2024-01-28T22-35-53Z - MinIO preallocates memory,
mc update compresses binary in transit MinIO SERVER
RELEASE.2024-02-06T21-36-22Z -

MinIO adds condition key for restricting STS AssumeRoleWithWebIdentity
duration at policy level

Closes #1124 , 

Partially addresses #1116 
Partially Addresses #1105


---------

Co-authored-by: Daryl White <53910321+djwfyi@users.noreply.github.com>

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

@@ -11,14 +11,8 @@ Deploy MinIO: Single-Node Single-Drive
    :depth: 2
 
 The procedures on this page cover deploying MinIO in a Single-Node Single-Drive (SNSD) configuration for early development and evaluation.
-|SNSD| deployments provide no added reliability or availability beyond what the underlying storage volume implements (RAID, LVM, ZFS, etc.).
-
-Starting with :minio-release:`RELEASE.2022-06-02T02-11-04Z`, MinIO implements a zero-parity erasure coded backend for single-node single-drive deployments.
-This feature allows access to :ref:`erasure coding dependent features <minio-erasure-coding>` without the requirement of multiple drives.
-This mode **requires** accessing stored objects through the S3 API, and does **not** support direct access to objects through the filesystem/POSIX interface.
-
-MinIO only starts in |SNSD| mode if the storage volume or path is empty *or* only contain files generated by a previous |SNSD| deployment.
-See the documentation on :ref:`SNSD behavior with pre-existing data <minio-snsd-pre-existing-data>` for more information.
+|SNSD| deployments use a zero-parity erasure coded backend that provides no added reliability or availability beyond what the underlying storage volume implements.
+These deployments are best suited for local testing and evaluation, or for small-scale data workloads that do not have availability or performance requirements.
 
 .. cond:: container
 
@@ -67,6 +61,37 @@ The following table lists the possible storage volume states and MinIO behavior:
 
        .. versionchanged:: RELEASE.2022-10-29T06-21-33Z
 
+Prerequisites
+-------------
+
+Storage Requirements
+~~~~~~~~~~~~~~~~~~~~
+
+The following requirements summarize the :ref:`minio-hardware-checklist-storage` section of MinIO's hardware recommendations:
+
+Use Local Storage
+   Direct-Attached Storage (DAS) has significant performance and consistency advantages over networked storage (:abbr:`NAS (Network Attached Storage)`, :abbr:`SAN (Storage Area Network)`, :abbr:`NFS (Network File Storage)`).
+   MinIO strongly recommends flash storage (NVMe, SSD) for primary or "hot" data.
+
+Use XFS-Formatting for Drives
+   MinIO strongly recommends provisioning XFS formatted drives for storage.
+   MinIO uses XFS as part of internal testing and validation suites, providing additional confidence in performance and behavior at all scales.
+
+Persist Drive Mounting and Mapping Across Reboots
+   Use ``/etc/fstab`` to ensure consistent drive-to-mount mapping across node reboots.
+
+   Non-Linux Operating Systems should use the equivalent drive mount management tool.
+
+Memory Requirements
+~~~~~~~~~~~~~~~~~~~
+
+.. versionchanged:: RELEASE.2024-01-28T22-35-53Z
+
+   MinIO pre-allocates 2GiB of system memory at startup.
+
+MinIO recommends a *minimum* of 32GiB of memory per host.
+See :ref:`minio-hardware-checklist-memory` for more guidance on memory allocation in MinIO.
+
 .. _deploy-minio-standalone:
 
 Deploy Single-Node Single-Drive MinIO
@@ -83,9 +108,6 @@ The following procedure deploys MinIO consisting of a single MinIO server and a
    MinIO cannot provide consistency guarantees if the underlying storage
    volumes are NFS or a similar network-attached storage volume. 
 
-   For deployments that *require* using network-attached storage, use
-   NFSv4 for best results.
-
 .. cond:: linux
 
    .. include:: /includes/linux/steps-deploy-minio-single-node-single-drive.rst