PUT Object

Resolving conflicts

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.

Object size

StorageGRID Webscale supports objects up to 5 TB in size.

Object ownership

In StorageGRID Webscale, all objects are owned by the bucket owner account, including objects created by a non-owner account or an anonymous user.

Storage class options

The x-amz-storage-class request header is supported with the following values:

• STANDARD

  (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.

• REDUCED_REDUNDANCY

  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.

  Note: You cannot use the REDUCED_REDUNDANCY option if you are ingesting an object into an S3 compliant bucket. This is to ensure that compliance requirements are satisfied (two copies of each object exist) before the object is evaluated by the active ILM policy. See the instructions for administering StorageGRID Webscale.

Request headers

The following request headers are supported:

• x-amz-tagging
• x-amz-server-side-encryption
• x-amz-meta-, followed by a name-value pair containing user-defined metadata
  When specifying the name-value pair for user-defined metadata, use this general format:

  x-amz-meta-name: value

  If you want to use the User Defined Creation Time option as the Reference Time for an ILM rule, you must use creation-time as the name of the metadata that records when the object was created. For example:

  x-amz-meta-creation-time: 1443399726

  The value for creation-time is evaluated as seconds since January 1, 1970.

  Note: Adding creation-time as user-defined metadata is not supported if you are adding an object to a S3 compliant bucket. An error will be returned.

The following request headers are not supported and return XNotImplemented:

• x-amz-server-side-encryption-customer-algorithm
• x-amz-server-side-encryption-customer-key
• x-amz-server-side-encryption-customer-key-MD5
• x-amz-website-redirect-location

Versioning

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.