Policy-based capacity optimization with IBM Storage Scale AFM to Cloud Object Storage and AWS S3

Introduction

One of the most common challenges in large-scale file storage environments is balancing performance, capacity, and cost. While active data benefits from residing on high-performance storage systems, a significant portion of enterprise data becomes inactive shortly after it is created. Keeping inactive data on expensive primary storage increases infrastructure cost and capacity requirements.

In several customer projects, I have used IBM Storage Scale Active File Management (AFM) to Cloud Object Storage to implement automated tiering from an on-premises Storage Scale cluster to external AWS S3 object storage. This approach reduces on-premises storage consumption while maintaining transparent user access to files.

In this context, tiering means that file contents are migrated from the Storage Scale file system to object storage. After migration, the file data no longer consumes significant capacity in the on-premises file system. A small amount of metadata remains locally, allowing users to continue listing and accessing files through the familiar namespace. When an evicted file is accessed, Storage Scale automatically fetches its data from object storage into the AFM cache.

The result combines the performance and usability of a file system with the scalability and cost characteristics of object storage.

In this blog article I demonstrate a solution leveraging IBM Storage Scale Active File Management in Manual Updates mode (AFM MU mode). To learn more about AFM to cloud object storage in general I recommend reviewing these blog articles: Hybrid Cloud Data Sharing with IBM Storage Scale and Practical Use Cases for IBM Storage Scale AFM To Cloud Object Storage.

Solution Architecture and Concepts

Architectural Overview

The solution uses a Storage Scale fileset configured as an AFM to Cloud Object Storage cache in Manual Updates (MU) mode. The fileset connects to an external AWS S3 bucket. Storage Scale ILM policies identify files to upload and evict, while protocol services provide normal file access to users and applications.

Figure 1. Policy-based tiering from an on-premises Storage Scale cluster to AWS S3.

AFM to Cloud Object Storage

AFM to Cloud Object Storage integrates a Storage Scale fileset with an object storage repository. The fileset acts as a cache and the object store acts as the backing store. Files in the cache can be uploaded as objects, and object data can be fetched into the cache and presented as regular files. AFM supports different operating modes for different synchronization and data-management requirements.

File Eviction

Files that have a valid copy in object storage can be evicted from the AFM cache. Eviction removes the locally allocated data blocks while retaining the inode and namespace metadata. Users can still list and open the file. The first access to an evicted file triggers a fetch from object storage.

Eviction can be triggered based on cache quota limits or initiated administratively with mmafmcosctl functionality.

Manual Updates Mode

In MU mode, newly created or modified files are not automatically replicated to object storage. Administrators control upload, eviction and deletion through explicit operations and policies. In MU mode, there is a single command allowing to identify, upload, evict and delete files. The identification of files can be controlled through custom Storage Scale ILM policies. File identified by the policy are uploaded and evicted. In addition, files that were deleted in the AFM MU fileset are deleted in the object storage. This enables tiering decisions based on age, access patterns, size, location, ownership, or business-specific criteria.

Storage Scale ILM Policies

Storage Scale ILM policies describe lifecycle rules for files. The policy engine evaluates file metadata and identifies matching files. For example, a policy could select files that are new or modified and have not been accessed for three days, then pass the selected files to AFM for upload and eviction.

Tiering Workflow with AFM and ILM policies

1. Files are stored in a Storage Scale fileset configured for AFM to Cloud Object Storage in MU mode
2. Storage Scale ILM policies identify files that should be migrated
3. Matching files are uploaded to object storage and evicted after successful upload, reclaiming local capacity.
4. The files remain visible in the Storage Scale namespace.
5. Accessing an evicted file automatically fetches its data from object storage.

Prerequisites

IBM Storage Scale configuration

The Storage Scale cluster must be configured and entitled for AFM to Cloud Object Storage. At least one node must have the AFM gateway role. The target file system also needs enough temporary capacity for new and recalled files before those files are evicted again.

Network connectivity

AFM gateway nodes require reliable HTTPS connectivity to the object storage endpoint. Available bandwidth and latency directly affect upload and recall performance.

AWS S3 configuration

Create the S3 bucket before configuring the AFM fileset. Restrict the credentials to the required bucket and actions wherever possible.

Data classification and policy criteria

Define which data may be tiered and what recall latency is acceptable before deploying a policy. Typical selection attributes include:

• Last access and modification times
• File size and directory location
• Ownership or project assignment
• Retention and compliance requirements

Deployment and Operation

Environment Information

The following information about the AWS S3 bucket is required:

Assign the AFM Gateway Role

At least one node in the cluster must have the gateway role. More than one node can be assigned the gateway role providing redundancy and parallel performance.

# mmchnode --gateway -N nodename

Store the AWS S3 Credentials

# mmafmcoskeys scale-afm-tier set <access-key> <secret-key>
# mmafmcoskeys scale-afm-tier get

Create the AFM Fileset

The following command creates the AFM to Cloud Object Storage fileset awstier in file system fs2 and links it under /ibm/fs2/awstier.

# mmafmcosconfig fs2 awstier --endpoint https://s3.amazonaws.com \
  --object-fs --xattr --bucket scale-afm-tier --mode mu --acls
# mmlsfileset fs2 awstier -L --afm

Store Sample Files in the Fileset

The following command list all files in the directory and shows the actual size of the files in the first column of the output:

# ls -lsh /ibm/fs2/awstier/dir1
total 15M
1.0M -rw-r--r--. 1 root root 1.0M Sep  9 10:46 file1
2.0M -rw-r--r--. 1 root root 2.0M Sep  9 10:46 file2
3.0M -rw-r--r--. 1 root root 3.0M Sep  9 10:46 file3
4.0M -rw-r--r--. 1 root root 4.0M Sep  9 10:46 file4
5.0M -rw-r--r--. 1 root root 5.0M Sep  9 10:46 file5

The first column of the ls -s output shows the blocks allocated in the Storage Scale file system. At this stage, all five files consume their full local allocation.

Create the Tiering Policy

The following policy identifies files that AFM considers dirty and therefore requiring synchronization, as well as files that currently have more than 1 KB allocated locally, such as previously recalled files. Dirty files are those that were newly created or modified. The hidden AFM directories are excluded.

define( is_dirty, ( REGEX(misc_attributes,'[P]') AND REGEX(misc_attributes,'[w|v|x|y|j]') ) )

RULE EXTERNAL LIST 'dirtyFiles'
RULE 'dirtyFilesRule' LIST 'dirtyFiles' WHERE
PATH_NAME NOT LIKE '/ibm/fs2/awstier/.pconflicts/%' AND
PATH_NAME NOT LIKE '/ibm/fs2/awstier/.afm/%' AND
PATH_NAME NOT LIKE '/ibm/fs2/awstier/.ptrash/%' AND
( is_dirty OR ( KB_ALLOCATED > 1 ) )

Associate and Verify the Policy

The policy is stored in file awstier.pol and applied to the fileset awstier:

# mmafmcosctl fs2 awstier /ibm/fs2/awstier reconcile --add-policy awstier.pol
# mmafmcosctl fs2 awstier /ibm/fs2/awstier reconcile --list-policy

Execute Tiering

The mmafmcosctl reconcile –evict-after-upload command executes the LIST policy and passes the selected files to AFM. Dirty files are uploaded to object storage, and eligible files are evicted after successful upload. In the last step this command deletes file in object storage that were deleted in the AFM MU fileset:

# mmafmcosctl fs2 awstier /ibm/fs2/awstier reconcile --evict-after-upload
Dirty file list : /var/mmfs/afm/fs2-1/recovery/policylist.data.list.dirtyFiles
Threads in use: 1
     Queued    (Total)      Failed                TotalData
                                                  (approx in Bytes)
          5         (5)           0                 15728640
Object Upload successfully queued at the gateway.
mmafmcosctl: Could not find any deleted files.

AFM MU mode provides a single command (reconcile) that identifies, uploads, evicts and deletes eligible files in object storage. Upload, eviction and deletion can also be executed as separated mmafmcosctl commands (see mmafmcosctl command reference for details).

Verify Eviction

The first column of the command now shows only a minimal allocation, 512 bytes in this example. The file data blocks have been evicted while AFM cache metadata and the namespace entry remain. The exact residual allocation can vary and should not be interpreted as a fixed metadata size.

# ls -lsh /ibm/fs2/awstier/dir1
512 -rw-r--r--. 1 root root 1.0M Sep  9 10:46 file1
512 -rw-r--r--. 1 root root 2.0M Sep  9 10:46 file2
512 -rw-r--r--. 1 root root 3.0M Sep  9 10:46 file3
512 -rw-r--r--. 1 root root 4.0M Sep  9 10:46 file4
512 -rw-r--r--. 1 root root 5.0M Sep  9 10:46 file5

Verify the Objects in AWS S3

In this example the awscli is used to list the bucket scale-afm-tier:

$ aws s3 ls s3://scale-afm-tier/dir1/
2026-09-09 10:49:22    1048576 file1
2026-09-09 10:49:21    2097152 file2
2026-09-09 10:49:22    3145728 file3
2026-09-09 10:49:21    4194304 file4
2026-09-09 10:49:21    5242880 file5

The file contents are present as objects in the S3 bucket while the files remain visible through the Storage Scale namespace.

Access an Evicted File

Reading file1 fetches its data from S3 into the AFM cache. The file therefore consumes 1 MB locally again, while the other files remain evicted. At this point file1 was not modified, just read.

# file /ibm/fs2/awstier/dir1/file1
/ibm/fs2/awstier/dir1/file1: data

# ls -lsh /ibm/fs2/awstier/dir1
total 1.1M
1.0M -rw-r--r--. 1 root root 1.0M Sep  9 10:46 file1
 512 -rw-r--r--. 1 root root 2.0M Sep  9 10:46 file2
 512 -rw-r--r--. 1 root root 3.0M Sep  9 10:46 file3
 512 -rw-r--r--. 1 root root 4.0M Sep  9 10:46 file4
 512 -rw-r--r--. 1 root root 5.0M Sep  9 10:46 file5

Re-evict the Recalled File

The following command executes the policy again and uploads and deletes required files in object storage and evicts eligible files:

# mmafmcosctl fs2 awstier /ibm/fs2/awstier reconcile --evict-after-upload
Dirty file list : /var/mmfs/afm/fs2-1/recovery/policylist.data.list.dirtyFiles
Threads in use: 1
     Queued    (Total)      Failed                TotalData
                                                  (approx in Bytes)
          1         (1)           0                  1048576
Object Upload successfully queued at the gateway.
mmafmcosctl: Could not find any deleted files.

Because the policy selects files with KB_ALLOCATED > 1, the recalled file (file1) becomes eligible for eviction again. It is not uploaded again, because it was not modified. Repeated execution therefore reclaims cache capacity.

Production Considerations

Policy scheduling

Schedule the reconcile operation with cron, a systemd timer, an enterprise scheduler, or an automation framework. Choose the interval based on capacity pressure, acceptable upload traffic, and operational windows.

Policy safety and rollout

Validate policies with representative data before broad deployment. Start with a constrained path or conservative selection criteria, review the resulting file list and AFM activity, and then expand the scope.

Recall behavior and thrashing

The first read of an evicted file incurs object-storage and network latency. Avoid policies that repeatedly recall and evict active data. Age-based criteria and appropriate grace periods reduce churn.

Monitoring and reconciliation

Monitor AFM gateway health, queue progress, failed uploads, recalls, cache utilization, network throughput, and S3 capacity. Do not treat a queued message alone as proof that every transfer and eviction has completed successfully.

High availability and throughput

Use multiple appropriately sized AFM gateway nodes in production to improve resilience and throughput. Validate failover behavior and ensure each gateway has suitable CPU, memory, network connectivity, and name resolution.

Security and credentials

Use HTTPS, least-privilege bucket permissions, secure credential storage, credential rotation, audit logging, and encryption at rest. Protect the object bucket because evicted files depend on the object copy for subsequent recall.

AWS S3 cost and lifecycle controls

Account for stored capacity, request charges, retrieval, and data transfer. Confirm that S3 lifecycle transitions and retention controls remain compatible with the required AFM access and recall behavior before enabling them.

Data protection and recovery

Tiering is not a backup. Define independent protection for the Storage Scale namespace and object data, and test recovery of both components. Coordinate snapshots, backup, versioning, retention, and deletion behavior with AFM requirements.

AWS S3 Bucket Versioning can be used on the target bucket and is transparent to AFM. AFM fetches the latest version of an object. If versions of objects are required, then these must be retrieved using the S3 get-object request with parameter –version-id and copied into the original name space of the AFM MU fileset.

Operational change control

Document ownership, schedules, exclusions, incident handling, credential rotation, capacity thresholds, and rollback procedures. Revalidate the configuration after Storage Scale, network, or object-storage changes.

Conclusion

AFM to Cloud Object Storage in Manual Updates mode provides a practical foundation for policy-based file tiering from IBM Storage Scale to AWS S3 and other supported object storage platforms. Storage Scale ILM policies select data, AFM uploads and evicts eligible files, and transparent recall preserves the file-system access model for users and applications.

When combined with careful policy design, monitoring, security, high availability, and independent data protection, the approach can reduce primary-storage consumption and extend effective file-system capacity without requiring application changes.