of the previous version.

## Inline Data

Inline data is optional. If no inline data is present, it is encoded as 0 bytes.

| Entry               | Encoding                    | Content
| --------------------|-----------------------------|----------------------------------------
| xlMetaInlineDataVer | byte                        | version identifier

lifecycle transition rules and becomes eligible for tiering. MinIO scanner (which runs at one minute intervals, each time scanning one sixteenth of the namespace), picks up the object for tiering. The data is moved to the remote tier in entirety, leaving only the object metadata on MinIO.

The data on the backend is stored under the `bucket/prefix` specified in the tier configuration with a custom name derived from a randomly generated uuid - e.g. `0b/c4/0bc4fab7-2daf-4d2f-8e39-5c6c6fb7e2d3`....

## Overview

Replication relies on immutability provided by versioning to sync objects between the configured source and replication target. Replication results in the object data, metadata, last modification time and version ID all being identical between the source and target. Thus version ordering is automatically guaranteed on the source and target clusters.

### Replication of object version and metadata

```
minio server /mnt/controller{1...4}/data{1...16}
```

Standalone erasure coded configuration with 16 sets, 16 drives per set, across mounts and controllers.

```
minio server /mnt{1...4}/controller{1...4}/data{1...16}
```

Distributed erasure coded configuration with 2 sets, 16 drives per set across hosts.

```