Supported Functionality and Known Limits for S3 in Qumulo Core

This section documents Qumulo Core support for S3 API functionality and S3 API limits.

Supported S3 API Actions

The following table lists the S3 API actions that Qumulo Core supports and the version from which support begins. For the full list of S3 API actions, see Actions in the Amazon Simple Storage Service API Reference.

API Action	Supported from Qumulo Core Version
AbortMultipartUpload	5.3.3
CompleteMultipartUpload	5.3.3
CopyObject	5.3.3
CreateBucket	5.2.3
CreateMultipartUpload	5.3.3
DeleteBucket	5.2.4
DeleteBucketPolicy	7.0.1.1
DeleteBucketVersioning	7.1.2
DeleteObject	5.2.1
DeleteObjects	5.2.2
DeleteObjectTagging	6.3.2
GetBucketAcl	6.1.1
GetBucketLocation	5.1.2
GetBucketPolicy	7.0.0.1
GetBucketVersioning	7.1.2
GetObject	5.0.4
GetObjectAcl	6.1.1
GetObjectLegalHold	7.2.3.2
GetObjectLockConfiguration	7.0.0.1
GetObjectRetention	7.2.1.1
GetObjectTagging	7.1.2
HeadBucket	5.1.2
HeadObject	5.0.4
ListBuckets	5.0.4
ListMultipartUploads	5.3.3
ListObjects	5.0.5
ListObjectsV2	5.0.4
ListParts	5.3.3
PutBucketPolicy	7.0.1.1
PutBucketVersioning	7.1.2
PutObject	5.2.1
PutObjectLegalHold	7.2.3.2
PutObjectLockConfiguration	7.2.3.2
PutObjectRetention	7.2.1.1
PutObjectTagging	6.3.2
UploadPart	5.3.3
UploadPartCopy	6.0.2

Unsupported S3 Functionality

The following table lists some of the S3 API functionality that Qumulo Core doesn’t support.

Unsupported Feature	Description
BitTorrent	—
Bucket ACLs	For comparable functionality, use inheritable access control entries (ACEs).
Bucket lifecycle configurations	—
Bucket notifications	—
Control of server-side encryption	All Qumulo Core data is encrypted at rest. You can’t control this functionality by using the S3 API.
Object Lock in governance mode	Qumulo Core supports only compliance mode.
Logging controls	—
Multi-chunk payload signing	Qumulo Core has partial support for the streaming variants of AWS Signature Version 4 (SigV4).
AWS Signature Version 2	Qumulo Core supports only SigV4 signatures.
Storage classes	Qumulo Core doesn’t use the storage class concept. All objects have the same storage class status.
Temporary access credentials	—
Virtual-hosted bucket addressing	Qumulo Core supports only path-style bucket addressing.
Web hosting configuration	—

S3 API Limitations

This section describes the most important S3 API limitations in Qumulo Core.

Authentication

Supported STREAMING-UNSIGNED-PAYLOAD-TRAILER Checksum Formats

• CRC64-NVME
• SHA-256

Supported x-amz-content-sha256 Header Values

• <actual payload checksum>
• UNSIGNED-PAYLOAD
• STREAMING-UNSIGNED-PAYLOAD-TRAILER
• STREAMING-AWS4-HMAC-SHA256-PAYLOAD
• STREAMING-AWS4-HMAC-SHA256-PAYLOAD-TRAILER

Use Cases for Supported x-amz-content-sha256 Header Values

SigV4 uses the x-amz-content-sha256 header to specify the authentication type to perform. The following table lists the supported values for the x-amz-content-sha256 header that Qumulo Core supports, the number of chunks for a payload, and the produced signature type.

Header Value	Qumulo Core Support	Use When	Signature Type
CRC32	❌	—	—
CRC32C	❌	—	—
<actual payload checksum>	✅	Sending a payload in a single chunk	—
UNSIGNED-PAYLOAD	✅	Sending a payload in a single chunk	Unsigned
STREAMING-UNSIGNED-PAYLOAD-TRAILER	Partial	Sending a payload in multiple chunks Note The digest for the chunks is included as a trailing header.	Unsigned
STREAMING-AWS4-HMAC-SHA256-PAYLOAD	✅	Sending a payload in multiple chunks Signing the chunks by using the AWS4-HMAC-SHA256 algorithm	SigV4 signature
STREAMING-AWS4-HMAC-SHA256-PAYLOAD-TRAILER	Partial	Sending a payload in multiple chunks Note The digest for the chunks is included as a trailing header. Signing the chunks by using the AWS4-HMAC-SHA256 algorithm	SigV4 signature

Bucket Addressing Style

Because Qumulo Core supports only path-style bucket addressing, you must configure your client applications to use path-style addressing to send S3 API requests to a Qumulo cluster. For more information, see Configuring the AWS CLI for Use with Qumulo Core.

ETags

RESTful APIs, such as the Qumulo Core S3 API, use HTTP ETags to identify different resource versions. When working with files by using Qumulo Core, each time a file’s contents change (regardless of protocol), the value of its ETag changes as well.

• Qumulo Core doesn’t maintain a checksum value for every object in an S3 bucket because other protocols, such as NFS or SMB, can modify portions of the same file, which causes changes to a file to make the checksum inaccurate.

• Amazon S3 uses the MD5 checksum of an object’s contents as its ETag.

Listing Objects

The S3 API supports listing objects in a bucket by using the ListObjects and ListObjectsV2 API actions.

Function	Qumulo Core	Amazon S3
Returning results	Consistent but non-alphabetical order	Alphabetical order, by object key
Arbitrary prefix	Partial support for Prefix, only if Prefix is a path to a file or directory under the bucket root directory	Prefix limits results to object keys that begin with the prefix
Arbitrary delimiter	Only the slash (/) character can act as Delimiter	Delimiter groups results into common prefixes

Object Metadata

Qumulo Core stores each kind of S3 object metadata as user-defined metadata in a separate keyspace.

S3 Object Metadata	Appears to S3 Clients As…	Qumulo Core Keyspace
User-Defined Metadata	x-amz-meta-* headers	S3
Tags	One of the following: x-amz-tagging header PutObjectTagging API action	GENERIC
Standard object headers	Cache-Control Content-Disposition Content-Encoding Content-Language Content-Type Expires	WELL_KNOWN

Special Considerations for Standard Object in Qumulo Core

This section describes the special considerations for how default header values, header storage and replication, and response header overrides work in Qumulo Core.

Default Header Values

• Content-Type: If an object has no stored Content-Type value (for example, if it is a file written by using NFS or SMB or an object written by using a version of Qumulo Core lower than 7.10.2), the GetObject and HeadObject API actions return Content-Type: binary/octet-stream.

• Content-Encoding: The AWS SDK adds aws-chunked to the Content-Encoding header of streaming uploads. Following Amazon S3 behavior, Qumulo Core removes aws-chunked from the stored value. If no other Content-Encoding value remains, Qumulo doesn’t store this header.

Header Storage

• Creating Objects:

  • Qumulo Core stores the headers from the requests of PutObject and CreateMultipartUpload API actions.

  • For multipart uploads, the request headers of UploadPart API actions don’t change the stored values.

• Copying Objects:

  • The CopyObject API action copies the source object’s standard headers together with its user-defined metadata.

  • When you set the x-amz-metadata-directive header to REPLACE, Qumulo Core stores the standard headers and user-defined metadata from the request of the CopyObject API action.

Header Replication

• Qumulo Core continuous replication copies the stored headers only to target clusters that run Qumulo Core 7.10.2 (or higher).

• In Qumulo Core 7.10.2…

  • Qumulo Shift-To doesn’t send the stored headers to Amazon S3.

  • Qumulo Shift-From doesn’t store the headers of the objects that it copies.

Response Header Overrides

For presigned requests that use the following request types, you can use response header overrides as query parameters for the GetObject and HeadObject API actions.

• response-cache-control
• response-content-disposition
• response-content-encoding
• response-content-language
• response-content-type
• response-expires

For more information, see the following Amazon S3 documentation:

• GetObject: Overriding response header values through the request
• HeadObject: URI Request parameters (response-*)

Request Authentication

• Qumulo Core supports authenticating requests by using only Amazon Signature Version 4. Most S3 client applications support this authentication type.

  If your application attempts to use a previous Amazon signature version, you receive a 400 Bad Request response with the error code AuthorizationHeaderMalformed.

• Qumulo Core accepts only presigned requests where the X-Amz-Expires query parameter is set to a value of up to 604,800 seconds (7 days).

Versioning

• Object Version Limits: In Qumulo Core, S3 bucket versioning is consistent with that of Amazon S3, with the exception of individual object versions. Qumulo Core limits directories to approximately 4.3 billion child files. The approach that Qumulo Core takes to indexing files in a directory might cause object creation commands to output the QumuloDirectoryEntryLimitReached error when a directory gets close to its capacity. Because Qumulo Core gives object versions unique identifiers, it might be possible to retry the command successfully. However, if you begin to observe this error, we recommend removing previous object versions from your system.

• Creating Empty Versioned Directories: Qumulo Core doesn’t support creating empty, versioned directories.

• Deleting Versioned Objects: If you don’t specify an object version ID, the DeleteObject and DeleteObjects S3 API actions create a deletion marker for an object but don’t delete any file system data. Because currently Qumulo Core doesn’t support bucket lifecycle policies, the data remains accessible by using S3 API actions and the object version ID. To delete a specific object version permanently, specify its version ID when you use either of these API actions.

Object Lock

While native Amazon S3 functionality requires Object Lock to be enabled for an S3 bucket to be able to both modify and view locks on objects, Qumulo Core requires Object Lock to be enabled for an S3 bucket only to modify locks on objects.

Comparison of Known Limits between S3 in Qumulo and Amazon

This section compares the Qumulo Core S3 API limits with native Amazon S3 limits.

Known Limits for S3 Buckets

Limit	Qumulo Core	Amazon S3
Maximum number of buckets	16,000	1,000
Maximum number of objects in one bucket	Nominally unlimited	Unlimited
Minimum bucket name length	3 characters
Maximum bucket name length	63 characters

Known Limits for S3 Objects

This section lists the known minimum and maximum limits for S3 objects.

Minimum Limits

Limit	Qumulo Core	Amazon S3
Object size	0 bytes
Object key length	1 character

Maximum Limits

Limit	Qumulo Core	Amazon S3
Object size when using the PutObject API action	5 GiB
Object size when using the MultipartUpload API action	48.8 TiB (10,000 * 5 GiB)
Object key length	1,530 characters, if there are no slash (/) characters in the key	1,024 characters
Object versions	4,294,967,296 (theoretical)	Unlimited
Number of user-defined metadata (x-amz-meta-*) entries	100	—
Size of user-defined metadata (x-amz-meta-*) headers	2 KiB (2,048 bytes) combined key bytes and value bytes
Size of standard object headers	2 KiB (2,048 bytes) combined header name bytes and value bytes

Known Limits for S3 Multipart Uploads

Limit	Qumulo Core	Amazon S3
Minimum part ID	1
Maximum part ID	10,000
Minimum number of parts for each upload	1
Maximum number of parts for each upload	10,000
Minimum part size	5 MiB (except for the last part of an upload)
Maximum part size	5 GiB
Additional part size requirements	Must be a multiple of 4 KiB (4,096 bytes), except for the last part of an upload	—

Known Limits for S3 API Requests

Maximum Limit	Qumulo Core	Amazon S3
Object keys that the DeleteObjects API action specifies	Nominally unlimited	1,000
Buckets that the ListBuckets API action returns	16,000	1,000
Objects that the ListObjects and ListObjectsV2 API actions return	1,000
Parts that the ListParts API action returns	Unlimited	1,000
Uploads that the ListMultipartUploads API action returns	1,000

In addition, the following API actions have the Qumulo-specific maximum payload size limit of 10 MiB.

• CompleteMultipartUpload
• CreateBucket
• DeleteObjects

Related Topics

• Configuring and Using the S3 API
• Creating and Managing S3 Access Keys
• Creating and Managing S3 Buckets
• Managing Access to S3 Buckets
• Managing Access Policies for S3 Buckets
• Managing Multipart S3 Uploads
• Managing S3 Bucket Versioning
• Managing Object Lock for S3 Buckets