Chapter 4. Automated tiering 59
File placement policies are evaluated and applied at the time of file creation. If placement
policies are not defined, all new files are placed in the
system storage pool.
For example, assume that the client is going to create four files within one directory, and the
files are to be accessible within this namespace, regardless of physical location. The initial
policy creates .dbx and .log files in the gold storage pool, and all other files of a size less then
10 GB are placed in the silver storage pool. The client’s file requirements are as follows:
file01.dbx is a database index file that needs to sustain a high I/O rate
file02.dbf is a database file with an average I/O rate
file03 is a large file that is generally read sequentially
file04.log is a log file that, when active, needs to sustain a relatively high I/O rate
This policy can be implemented as shown in Example 4-1, which defines a default rule and an
additional three file placement rules. Any name can be assigned to a storage pool. For
illustration purposes, in Example 4-1, the default storage pool is named
silver; however, in a
real-world scenario, this might typically be named,
Example 4-1 Initial placement policy
RULE 'default' set pool 'silver'
RULE 'dbxfiles' set pool 'gold' where upper(name) like '%DBX'
RULE 'logfiles' set pool 'gold' where upper(name) like '%LOG'
RULE 'bigfiles' set pool 'bronze' where KB_ALLOCATED>10000000
4.3.2 SONAS automated tiering
Files, such as log files, can become obsolete or not accessed for a period of time. Hence,
they do not need to be placed in the highest performing storage pool. Example 4-2 shows the
rules for migrating file04.log through the storage pools. Policy rules are Structured Query
Language- (SQL)-like statements that specify the conditions for which the rule is to be
Example 4-2 Migration policy
RULE 'cleangold' migrate from pool 'gold' to pool 'silver' where access_age > 30 days
RULE 'cleansilver' migrate from pool 'silver' to pool 'bronze' where access_age > 90 days
RULE 'cleanbronze' migrate from pool 'bronze' to pool 'tape' where access_age > 365 days
60 IBM System Storage Solutions for Smarter Systems
Migration and deletion rules can be scheduled using the chronological scheduler. File
migration between pools can also be controlled by specifying thresholds, such as the percent
of storage pool used. A migration example is shown in Figure 4-9.
Figure 4-9 Contents of the file04.log file migrated to a tape
File file04.log, after not being updated and accessed for a period of time, is moved
transparently between storage pools. Finally, if the file has not been accessed for 365 days, it
is moved to tape, but is still visible within the namespace (directory) and can be accessed at
When using HSM space management on a filesystem, each file in the filesystem can be in
one of three states:
Resident: The file resides on disk in the SONAS appliance.
Premigrated: The file resides both on the disk in the SONAS and in Tivoli Storage
Migrated: The file resides only in Tivoli Storage Manager.
As data is accessed by Common Internet File System (CIFS), Network File System (NFS),
or other protocol, when a migrated file is opened and a byte of data that is not in the SONAS
cache is accessed, that access triggers a Data Management Application Program Interface
(DMAPI) event in the SONAS. Because a recall from physical tape requires waiting for
cartridge fetching, tape drive loading, and tape movement to the desired file, physical tape
recalls can take a significant number of seconds to start, so the application needs to plan for
For additional details, see the information available at these websites:
gold silver bronze
storage pool policy engine