1
0
mirror of https://github.com/minio/docs.git synced 2025-07-30 07:03:26 +03:00

MinIO removed the version limit in a prior version (#1244)

This removes references to version limits and suggests using object
expiration rules to manage unneeded noncurrent versions.

There is no doc issue to track this.
This commit is contained in:
Daryl White
2024-06-13 10:37:37 -04:00
committed by GitHub
parent df011dc263
commit 0c5dc28687
4 changed files with 13 additions and 17 deletions

View File

@ -107,7 +107,8 @@ Parameters
:optional:
Enables :ref:`object versioning <minio-bucket-versioning>` on the new bucket.
When enabled, MinIO keeps up to 10,000 versions of each object.
With versioning enabled, by default MinIO allows up to the maximum value of an Int64 versions per object, or over 9.2 quintillion.
Define :ref:`object expiration <minio-lifecycle-management-create-expiry-rule>` rules to remove versions of objects no longer needed, such as by the number of versions or the date of versions.
Versioning is required for :ref:`bucket replication <minio-bucket-replication>` or :ref:`site replication <minio-site-replication-overview>`.
Versioning does not imply or require object locking.

View File

@ -371,12 +371,17 @@ Maximum Object Versions
*Optional*
Overrides the default maximum version per object limit of ``10000`` with the user specified value.
Defines the default maximum versions to allow per object.
.. important::
By default, MinIO allows up to the maximum value of an Int64 versions per object, or over 9.2 quintillion.
The default limit of 10,000 provides a safety valve against incorrect or inefficient application behavior in versioned buckets.
Lifting this limit without first ensuring your applications are designed for versioned operations may result in a negative performance impact over time.
.. note::
MinIO versions from ``RELEASE.2023-08-04T17-40-21Z``to ``RELEASE.2024-03-26T22-10-45Z`` had a default limit of 10,000 object versions.
This setting can be used to override that limit to another value.
Arbitrarily high versions per objects may cause performance degradation on some operations, such as ``LIST``.
This is especially true on systems running budget hardware or spinning drives (HDD).
Applications or workloads which produce thousands or more versions per object may require design or architecture review to mitigate potential performance degradations.
Setting a limit of no more than ``100`` should provide enough versions for most typical use cases.