If an object meets replication rules as set in the replication configuration, `X-Amz-Replication-Status` is first set to `PENDING` as the PUT operation completes and replication is queued (unless synchronous replication is in place). After replication is performed, the metadata on the source object version changes to `COMPLETED` or `FAILED` depending on whether replication succeeded. The object version on the target shows `X-Amz-Replication-Status` of `REPLICA`

Refer to the sizing guide with details on the default parity count chosen for different erasure stripe sizes [here](https://github.com/minio/minio/blob/master/docs/distributed/SIZING.md)

MinIO places new objects in server pools based on proportionate free space, per pool. Following pseudo code demonstrates this behavior.

```go
func getAvailablePoolIdx(ctx context.Context) int {

Lifecycle transition rules can be applied to buckets (both versioned and un-versioned) by specifying the tier name defined above as the transition storage class for the lifecycle rule.

## Implementation

| xlVersion | [4]byte     | `'1', ' ', ' ', ' '`
| xlMetaV2  | msgp object | All versions as single messagepack object
| [EOF] | |

### v1.1+

Version 1.1 added inline data, which will be placed after the metadata.

Therefore, the metadata is wrapped as a binary array for easy skipping.

| Entry          | Encoding       | Content
| ---------------|----------------|----------------------------------------