FabricPool tiering policies enable you to move data efficiently across tiers as data becomes hot or cold. Understanding the tiering policies helps you select the right policy that suits your storage management needs.

Types of FabricPool tiering policies

FabricPool tiering policies determine when or whether the user data blocks of a volume in FabricPool are moved to the cloud tier, based on the volume “temperature” of hot (active) or cold (inactive). The volume “temperature” increases when it is accessed frequently and decreases when it is not. Some tiering policies have an associated tiering minimum cooling period, which sets the time that user data in a volume of FabricPool must remain inactive for the data to be considered “cold” and moved to the cloud tier.

After a block has been identified as cold, it is marked as eligible to be tiered. A daily background tiering scan looks for cold blocks. When enough 4KB blocks from the same volume have been collected, they are concatenated into a 4MB object and moved to the cloud tier based on the volume tiering policy.

Data in volumes using the all tiering policy is immediately marked as cold and begins tiering to the cloud tier as soon as possible. It does not need to wait for the daily tiering scan to run.

You can use the volume object-store tiering show command to view the tiering status of a FabricPool volume. For more information, see the Command Reference.

The FabricPool tiering policy is specified at the volume level. Four options are available:

The snapshot-only tiering policy (the default) moves user data blocks of the volume Snapshot copies that are not associated with the active file system to the cloud tier.

The tiering minimum cooling period is 2 days. You can modify the default setting for the tiering minimum cooling period with the -tiering-minimum-cooling-days parameter in the advanced privilege level of the volume create and volume modify commands. Valid values are 2 to 183 days using ONTAP 9.8 and later. If you are using a version of ONTAP earlier than 9.8, valid values are 2 to 63 days.
The auto tiering policy, supported on ONTAP releases, moves cold user data blocks in both the Snapshot copies and the active file system to the cloud tier.

The default tiering minimum cooling period is 31 days and applies to the entire volume, for both the active file system and the Snapshot copies.

You can modify the default setting for the tiering minimum cooling period with the -tiering-minimum-cooling-days parameter in the advanced privilege level of the volume create and volume modify commands. Valid values are 2 to 183 days.
The all tiering policy, supported with ONTAP, moves all user data blocks in both the active file system and Snapshot copies to the cloud tier. It replaces the backup tiering policy.

The all volume tiering policy should not be used on read/write volumes that have normal client traffic.

The tiering minimum cooling period does not apply because the data moves to the cloud tier as soon as the tiering scan runs, and you cannot modify the setting.
The none tiering policy keeps a volume’s data in the performance tier and does not move cold to the cloud tier.

Setting the tiering policy to none prevents new tiering. Volume data that has previously been moved to the cloud tier remains in the cloud tier until it becomes hot and is automatically moved back to the local tier.

The tiering minimum cooling period does not apply because the data never moves to the cloud tier, and you cannot modify the setting.

When cold blocks in a volume with a tiering policy set to none are read, they are made hot and written to the local tier.

The volume show command output shows the tiering policy of a volume. A volume that has never been used with FabricPool shows the none tiering policy in the output.

What happens when you modify the tiering policy of a volume in FabricPool

You can modify the tiering policy of a volume by performing a volume modify operation. You must understand how changing the tiering policy might affect how long it takes for data to become cold and be moved to the cloud tier.

Changing the tiering policy from snapshot-only or none to auto causes ONTAP to send user data blocks in the active file system that are already cold to the cloud tier, even if those user data blocks were not previously eligible for the cloud tier.
Changing the tiering policy to all from another policy causes ONTAP to move all user blocks in the active file system and in the Snapshot copies to the cloud as soon as possible. Prior to ONTAP 9.8, blocks needed to wait until the next tiering scan ran.

Moving blocks back to the performance tier is not allowed.
Changing the tiering policy from auto to snapshot-only or none does not cause active file system blocks that are already moved to the cloud tier to be moved back to the performance tier.

Volume reads are needed for the data to be moved back to the performance tier.
Any time you change the tiering policy on a volume, the tiering minimum cooling period is reset to the default value for the policy.

What happens to the tiering policy when you move a volume

Unless you explicitly specify a different tiering policy, a volume retains its original tiering policy when it is moved in and out of a FabricPool-enabled aggregate.

However, the tiering policy takes effect only when the volume is in a FabricPool-enabled aggregate.
The existing value of the -tiering-minimum-cooling-days parameter for a volume moves with the volume unless you specify a different tiering policy for the destination.

If you specify a different tiering policy, then the volume uses the default tiering minimum cooling period for that policy. This is the case whether the destination is FabricPool or not.
You can move a volume across aggregates and at the same time modify the tiering policy.

You should pay special attention when a volume move operation involves the auto tiering policy.

Assuming that both the source and the destination are FabricPool-enabled aggregates, the following table summarizes the outcome of a volume move operation that involves policy changes related to auto:

When you move a volume that has a tiering policy of…	And you change the tiering policy with the move to…	Then after the volume move…
`all`	`auto`	All data is moved to the performance tier.
`snapshot-only`, `none`, or `auto`	`auto`	Data blocks are moved to the same tier of the destination as they previously were on the source.
`auto` or `all`	`snapshot-only`	All data is moved to the performance tier.
`auto`	`all`	All user data is moved to the cloud tier.
`snapshot-only`,`auto` or `all`	`none`	All data is kept at the performance tier.

When you move a volume that has a tiering policy of…

And you change the tiering policy with the move to…

Then after the volume move…

all

auto

All data is moved to the performance tier.

snapshot-only, none, or auto

auto

Data blocks are moved to the same tier of the destination as they previously were on the source.

auto or all

snapshot-only

All data is moved to the performance tier.

auto

all

All user data is moved to the cloud tier.

snapshot-only,auto or all

none

All data is kept at the performance tier.

What happens to the tiering policy when you clone a volume

Beginning with ONTAP 9.8, a clone volume always inherits both the tiering policy and the cloud retrieval policy from the parent volume.

In releases earlier than ONTAP 9.8, a clone inherits the tiering policy from the parent except when the parent has the all tiering policy.
If the parent volume has the never cloud retrieval policy, its clone volume must have either the never cloud retrieval policy or the all tiering policy, and a corresponding cloud retrieval policy default.
The parent volume cloud retrieval policy cannot be changed to never unless all its clone volumes have a cloud retrieval policy never.

When you clone volumes, keep the following best practices in mind:

The -tiering-policy option and tiering-minimum-cooling-days option of the clone only controls the tiering behavior of blocks unique to the clone. Therefore, we recommend using tiering settings on the parent FlexVol that are either move the same amount of data or move less data than any of the clones
The cloud retrieval policy on the parent FlexVol should either move the same amount of data or should move more data than the retrieval policy of any of the clones

How tiering policies work with cloud migration

FabricPool cloud data retrieval is controlled by tiering policies that determine data retrieval from the cloud tier to performance tier based on the read pattern. Read patterns can be either sequential or random.

The following table lists the tiering policies and the cloud data retrieval rules for each policy.

Tiering policy	Retrieval behavior
none	Sequential and random reads
snapshot-only	Sequential and random reads
auto	Random reads
all	No data retrieval

Tiering policy

Retrieval behavior

none

Sequential and random reads

snapshot-only

Sequential and random reads

auto

Random reads

all

No data retrieval

Beginning with ONTAP 9.8, the cloud migration control cloud-retrieval-policy option overrides the default cloud migration or retrieval behavior controlled by the tiering policy.

The following table lists the supported cloud retrieval policies and their retrieval behavior.

Cloud retrieval policy	Retrieval behavior
default	Tiering policy decides what data should be pulled back, so there is no change to cloud data retrieval with “default,” `cloud-retrieval-policy`. This policy is the default value for any volume regardless of the hosted aggregate type.
on-read	All client-driven data read is pulled from cloud tier to performance tier.
never	No client-driven data is pulled from cloud tier to performance tier
promote	For tiering policy “none,” all cloud data is pulled from the cloud tier to the performance tier For tiering policy “snapshot-only,” AFS data is pulled.

Cloud retrieval policy

Retrieval behavior

default

Tiering policy decides what data should be pulled back, so there is no change to cloud data retrieval with “default,” cloud-retrieval-policy. This policy is the default value for any volume regardless of the hosted aggregate type.

on-read

All client-driven data read is pulled from cloud tier to performance tier.

never

No client-driven data is pulled from cloud tier to performance tier

promote

For tiering policy “none,” all cloud data is pulled from the cloud tier to the performance tier
For tiering policy “snapshot-only,” AFS data is pulled.