accessKey:           credentials.AccessKey,
			secretKey:           credentials.SecretKey,
			malformedBody:       false,
			ignoreContentLength: false,
		},
		// Failed with entity too large.
		{
			objectName:          "test",
			data:                bytes.Repeat([]byte("a"), (1*humanize.MiByte)+1),
			expectedRespStatus:  http.StatusBadRequest,
			accessKey:           credentials.AccessKey,

     *
     * @return RDMA provider name ("auto", "disni", "tcp", etc.)
     */
    String getRdmaProvider();

    /**
     * Get RDMA read/write threshold
     *
     * Operations larger than this size will use RDMA read/write
     * instead of send/receive.
     *
     * @return threshold in bytes
     */
    int getRdmaReadWriteThreshold();

    /**
     * Get maximum RDMA send size

 *
 * <p>Unlike {@code java.util.HashSet}, iteration is only proportional to the actual {@code size()},
 * which is optimal, and <i>not</i> the size of the internal hashtable, which could be much larger
 * than {@code size()}. Furthermore, this structure only depends on a fixed number of arrays; {@code
 * add(x)} operations <i>do not</i> create objects for the garbage collector to deal with, and for

 *
 * <p>Unlike {@code java.util.HashMap}, iteration is only proportional to the actual {@code size()},
 * which is optimal, and <i>not</i> the size of the internal hashtable, which could be much larger
 * than {@code size()}. Furthermore, this structure places significantly reduced load on the garbage
 * collector by only using a constant number of internal objects.
 *

* kube-apiserver: a request body of a CREATE/UPDATE/PATCH/DELETE resource operation larger than 100 MB will return a 413 "request entity too large" error. ([#73805](https://github.com/kubernetes/kubernetes/pull/73805), [@caesarxuchao](https://github.com/caesarxuchao))

      // path when the first operation on the new map is putAll(otherMap). There, prior to
      // https://github.com/openjdk/jdk/commit/3e393047e12147a81e2899784b943923fc34da8e, a bug
      // meant that sometimes a too-large threshold is calculated. However, this new threshold is
      // independent of the initial capacity, except that it won't be lower than the threshold

      // path when the first operation on the new map is putAll(otherMap). There, prior to
      // https://github.com/openjdk/jdk/commit/3e393047e12147a81e2899784b943923fc34da8e, a bug
      // meant that sometimes a too-large threshold is calculated. However, this new threshold is
      // independent of the initial capacity, except that it won't be lower than the threshold

* Fix v1.17.0 regression in reflector relist causing master rolling upgrade to fail for large clusters due to excessive list calls to etcd ([#86824](https://github.com/kubernetes/kubernetes/pull/86824), [@jpbetz](https://github.com/jpbetz))

 * <p>The time taken to compute multiple quantiles on the same dataset using {@link Scale#indexes
 * indexes} is generally less than the total time taken to compute each of them separately, and
 * sometimes much less. For example, on a large enough dataset, computing the 90th and 99th
 * percentiles together takes about 55% as long as computing them separately.
 *
 * <p>When calling {@link ScaleAndIndex#compute} (in {@linkplain ScaleAndIndexes#compute either

const (
	// Maximum object size per PUT request is 5TB.
	// This is a divergence from S3 limit on purpose to support
	// use cases where users are going to upload large files
	// using 'curl' and presigned URL.
	globalMaxObjectSize = 5 * humanize.TiByte

	// Minimum Part size for multipart upload is 5MiB
	globalMinPartSize = 5 * humanize.MiByte