Volume storage capacity

FSx for ONTAP volumes are virtual resources that you use for grouping data, determining how data is stored, and determining the type of access to your data. Volumes, like folders, don't consume file system storage capacity themselves. Only the data that's stored in a volume consumes SSD storage and, depending on the volume's tiering policy, capacity pool storage. You set a volume's size when you create it, and you can change its size later. You can monitor and manage the storage capacity of your FSx for ONTAP volumes using the AWS Management Console, AWS CLI and API, and the ONTAP CLI.

Topics

• Volume data tiering
• Snapshots and volume storage capacity
• Volume file capacity
• Updating a volume's storage capacity
• Enabling volume autosizing
• Monitoring volume storage capacity
• Setting a volume's tiering policy
• Setting the minimum cooling days
• Setting a volume's cloud retrieval policy
• Viewing a volume's file capacity
• Increasing the maximum number of files on a volume
• Enabling a volume's cloud write mode

Volume data tiering

An Amazon FSx for NetApp ONTAP file system has two storage tiers: primary storage and capacity pool storage. Primary storage is provisioned, scalable, high-performance SSD storage that’s purpose-built for the active portion of your data set. Capacity pool storage is a fully elastic storage tier that can scale to petabytes in size and is cost-optimized for infrequently accessed data.

The data on each volume is automatically tiered to the capacity pool storage tier based on the volume's tiering policy, cooling period, and threshold settings. The following sections describe ONTAP volume tiering policies and the thresholds used to determine when data is tiered to the capacity pool.

Volume tiering policies

You determine how to use your FSx for ONTAP file system’s storage tiers by choosing the tiering policy for each of volume on the file system. You choose the tiering policy when you create a volume, and you can modify it at any time with the Amazon FSx console, AWS CLI, API, or using NetApp management tools. You can choose from one of the following policies that determine which data, if any, is tiered to the capacity pool storage.

Note

Tiering can move your file data and snapshot data to the capacity pool tier. However, file metadata always remains on the SSD tier. For more information, see How SSD storage is used.

• Auto – This policy moves all cold data—user data and snapshots—to the capacity pool tier. The cooling rate of data is determined by the policy's cooling period, which by default is 31 days, and is configurable to values between 2–183 days. When the underlying cold data blocks are read randomly (as in typical file access), they are made hot and written to the primary storage tier. When cold data blocks are read sequentially (for example, by an antivirus scan), they remain cold and remain on the capacity pool storage tier. This is the default policy when creating a volume using the Amazon FSx console.

• Snapshot Only – This policy moves only snapshot data to the capacity pool storage tier. The rate at which snapshots are tiered to the capacity pool is determined by the policy's cooling period, which by default is set to 2 days, and is configurable to values between 2–183 days. When cold snapshot data are read, they are made hot and written to the primary storage tier. This is the default policy when creating a volume using the AWS CLI, Amazon FSx API, or the NetApp ONTAP CLI.

• All – This policy marks all user data and snapshot data as cold, and stores it in the capacity pool tier. When data blocks are read, they remain cold and are not written to the primary storage tier. When data is written to a volume with the All tiering policy, it is still initially written to the SSD storage tier, and is tiered to the capacity pool by a background process. Note that file metadata always remains on the SSD tier.

• None – This policy keeps all of your volume’s data on the primary storage tier, and prevents it from being moved to capacity pool storage. If you set a volume to this policy after it used any other policy, existing data in the volume that was in capacity pool storage is moved to SSD storage by a background process as long as your SSD utilization is below 90%. This background process can be sped up by intentionally reading data or by modifying your volume's cloud retrieval policy. For more information, see Cloud retrieval policies.

As a best practice, when migrating data that you plan to store long-term in capacity pool storage, we recommend that you use the Auto tiering policy on your volume. With Auto tiering, data is stored on the SSD storage tier for a minimum of 2 days (based on the volume's cooling period) before it's moved to the capacity pool tier. Retaining data on SSD storage for at least 2 days allows ONTAP to run post-process compression and deduplication savings on your data, which are preserved when data is tiered to the capacity pool. ONTAP only runs post-process compression and deduplication for data on SSD storage, so selecting this policy can help you maximize your long-term storage savings. You can also maximize the transfer speeds of the first backups you create of your volumes, as the data that is being backed up is on SSD storage.

For more information about setting or modifying a volume's tiering policy, see Setting a volume's tiering policy.

Tiering cooling period

A volume's tiering cooling period sets the amount of time that it takes for data in the SSD tier to be marked as cold. The cooling period applies to the Auto and Snapshot-only tiering policies. You can set the cooling period to a value in the range of 2–183 days. For more information about setting the cooling period, see Setting the minimum cooling days.

Data is tiered 24–48 hours after its cooling period expires. Tiering is a background process that consumes network resources, and has a lower priority than client-facing requests. Tiering activities are throttled when there are ongoing client-facing requests.

Cloud retrieval policies

A volume's cloud retrieval policy sets the conditions that specify when data that's read from the capacity pool tier is allowed to be promoted to the SSD tier. When the cloud retrieval policy is set to anything other than Default, this policy overrides the retrieval behavior of your volume’s tiering policy. A volume can have one of the following cloud retrieval policies:

• Default – This policy retrieves tiered data based on the volume's underlying tiering policy. This is the default cloud retrieval policy for all volumes.

• Never – This policy never retrieves tiered data, regardless of whether the reads are sequential or random. This is similar to setting the tiering policy of your volume to All, except that you can use it with other policies–Auto, Snapshot-only–to tier data according to the minimum cooling period instead of immediately.

• On-read – This policy retrieves tiered data for all client-driven data reads. This policy has no effect when using the All tiering policy.

• Promote – This policy marks all of a volume’s data that's in the capacity pool for retrieval to the SSD tier. The data is marked the next time the daily background tiering scanner runs. This policy is beneficial for applications that have cyclical workloads that run infrequently, but require SSD tier performance when they do run. This policy has no effect when using the All tiering policy.

For information on setting a volume's cloud retrieval policy, see Setting a volume's cloud retrieval policy.

Tiering thresholds

A file system's SSD storage capacity utilization determines how ONTAP manages the tiering behavior for all of your volumes. Based on a file system's SSD storage capacity usage, the following thresholds set the tiering behavior as described. For information about how to monitor the capacity utilization of a volume's SSD storage tier, see Monitoring volume storage capacity.

Note

We recommend that you don't exceed 80% storage capacity utilization of your SSD storage tier. For scale-out file systems, this recommendation applies to both the total average utilization across all of your file system's aggregates and to the utilization of each individual aggregate. This ensures that tiering functions properly, and provides overhead for new data. If your SSD storage tier is consistently above 80% storage capacity utilization, you can increase your SSD storage tier's capacity. For more information, see Updating file system SSD storage and IOPS.

FSx for ONTAP uses the following storage capacity thresholds to manage tiering on volumes:

• <=50% SSD storage tier utilization – At this threshold, the SSD storage tier is considered to be underutilized, and only volumes that are using the All tiering policy have data tiered to capacity pool storage. Volumes with Auto and Snapshot-only policies don't tier data at this threshold.

• > 50% SSD storage tier utilization – Volumes with Auto and Snapshot-only tiering policies tier data based on the tiering minimum cooling days setting. The default setting is 31 days.

• >=90% SSD storage tier utilization – At this threshold, Amazon FSx prioritizes preserving space in the SSD storage tier. Cold data from the capacity pool tier is no longer moved into the SSD storage tier when read for volumes using Auto and Snapshot-only policies.

• >=98% SSD storage tier utilization – All tiering functionality stops when the SSD storage tier is at or above 98% utilization. You can continue to read from storage tiers, but you can't write to the tiers.

Snapshots and volume storage capacity

A snapshot is a read-only image of an Amazon FSx for NetApp ONTAP volume at a point in time. Snapshots offer protection against accidental deletion or modification of files in your volumes. With snapshots, your users can easily view and restore individual files or folders from an earlier snapshot.

Snapshots are stored alongside your file system's data, and they consume the file system's storage capacity. However, snapshots consume storage capacity only for the portions of files that changed since the last snapshot. Snapshots are not included in backups of your file system volumes.

Snapshots are enabled by default on your volumes, using the default snapshot policy. Snapshots are stored in the .snapshot directory at the root of a volume. You can manage volume storage capacity for snapshots in the following ways:

• Snapshot policies – Select a built-in snapshot policy or choose a custom policy that you created in the ONTAP CLI or REST API.

• Manually delete snapshots – Reclaim storage capacity by deleting snapshots manually.

• Create a snapshot autodelete policy – Create a policy that deletes more snapshots than the default snapshot policy.

• Turn off automatic snapshots – Conserve storage capacity by turning off automatic snapshots.

For more information, see Working with snapshots.

Volume file capacity

Amazon FSx for NetApp ONTAP volumes have file pointers that are used to store file metadata such as file name, last accessed time, permissions, size, and to serve as pointers to data blocks. These file pointers are called inodes, and each volume has a finite capacity for the number of inodes, which is called the volume file capacity. When a volume runs low on or exhausts its available files (inodes), you can't write additional data to that volume.

The number of file system objects—files, directories, Snapshot copies—a volume can contain is determined by how many inodes it has. The number of inodes in a volume increases commensurately with the volume's storage capacity (and the number of volume constituents for FlexGroup volumes). By default, FlexVol volumes (or FlexGroup constituents) with a storage capacity of 648 GiB or more all have the same number of inodes: 21,251,126. If you create a volume larger than 648 GiB and you want it to have more than 21,251,126 inodes, you must increase the maximum number of inodes (files) manually. For more information about viewing the maximum number of files for a volume, see Viewing a volume's file capacity.

The default number of inodes on a volume is 1 inode for every 32 KiB of volume storage capacity, up to a volume size of 648 GiB. For a 1 GiB volume:

Volume_size_in_bytes × (1 file ÷ inode_size_in_bytes) = maximum_number_of_files

1,073,741,824 bytes × (1 file ÷ 32,768 bytes) = 32,768 files

You can increase the maximum number of inodes that a volume can contain, up to a maximum of 1 inode for every 4 KiB of storage capacity. For a 1 GiB volume. this increases the maximum number of inodes or files from 32,768 to 262,144:

1,073,741,824 bytes × (1 file ÷ 4096 bytes) = 262,144 files

An FSx for ONTAP volume can have a maximum of 2 billion inodes.

For information about changing the maximum number of files that a volume can store, see Increasing the maximum number of files on a volume.