This section provides details on StorageGRID Webscale support for the S3 PUT Object operation.
Conflicting client requests, such as two clients writing to the same key, are resolved on a "latest-wins" basis. The timing for the "latest-wins" evaluation is based on when the StorageGRID Webscale system completes a given request, and not on when S3 clients begin an operation.
StorageGRID Webscale supports objects up to 5 TB in size.
In StorageGRID Webscale, all objects are owned by the bucket owner account, including objects created by a non-owner account or an anonymous user.
The x-amz-storage-class request header is supported with the following values:
(Default) Specifies a dual-commit ingest operation. As soon as an object is ingested, a second copy of that object is created and distributed to a different Storage Node. When the object is matched by an ILM rule in the active policy, StorageGRID Webscale determines if the initial, dual-commit copies satisfy the placement instructions in the rule. If they do not, the object is added to the ILM evaluation queue. When the object is re-evaluated, new object copies might need to be made in different locations, and the initial dual-commit copies might need to be deleted.
Specifies a single-commit ingest operation. Specify REDUCED_REDUNDANCY only if you need to limit redundant storage at the time of ingest and only if you are willing to risk the loss of object data. For example, you can lose data if the single copy is initially stored on a Storage Node that fails before ILM evaluation can occur.
Specifying REDUCED_REDUNDANCY only affects how many copies are created when an object is first ingested. It does not affect how many copies of the object are made when the object is evaluated by the active ILM policy. Using REDUCED_REDUNDANCY does not result in data being stored at lower levels of redundancy in the StorageGRID Webscale system.
The following request headers are supported:
x-amz-meta-name: value
x-amz-meta-creation-time: 1443399726The value for creation-time is evaluated as seconds since January 1, 1970.
The following request headers are not supported and return XNotImplemented:
If versioning is enabled for a bucket, a unique versionId is automatically generated for the version of the object being stored. This versionId is also returned in the response using the x-amz-version-id response header.
If versioning is suspended, the object version is stored with a null versionId and if a null version already exists it will be overwritten.