Integrated file system object migration

Integrated file system objects supported during both system migration and data synchronization stages

Table 1 lists the integrated file system object types that are migrated during both the system migration stage and also the data synchronization stage. When an integrated file system object with one of the types from this table is changed during data synchronization stage, the object is saved on the source node and restored on the copy node. For details on excluding objects from migration, see Configuring integrated file system files or integrated file system trees to avoid migration.

Integrated file system objects that are not supported for either system migration or data synchronization stages

Table 2 lists the integrated file system object types that are not supported by the system migration stage or the data synchronization stage. If any of these object types are changed while in the data synchronization stage, an entry will appear on the ITL, and the TRACKING_STATE column will contain INELIGIBLE.

There are specific integrated file system path names where Migrate While Active will avoid tracking changes to objects. Changes to objects under these paths are avoided to improve the performance characteristics of migration. These specific path names are frequently used by software products running on the local node and the related integrated file system activity typically would not be critical to migrate to the copy node.

Any integrated file system object created within the directories listed in Table 3, or within any subdirectory under these paths, is not tracked nor migrated during data synchronization.

After the system migration stage has completed, the expectation is that no IBM® i open source software products will be installed, updated, or removed on the source node. If any changes are made to open source software products on the source node, those changes will need to be repeated on the copy node after completion of Migrate While Active.

Before finalizing the migration to the copy node, the ITL should be reviewed to understand if there are objects that are ineligible to be synchronized, or objects that failed to migrate during final synchronization.

Comparing integrated file system files or integrated file system trees

A compare facility exists that can be used to determine if there are any differences within the integrated file system between the source and copy node. The IFS_OBJECT_STATISTICS table function in QSYS2 can be queried using the special form of target relational database name, QIBM_DB2M_00000, to compare between the source and copy nodes.

COMPARE_IFS will show you if there are any integrated file system objects that exist on only one of the nodes, and if so, which node. The compare facility will also compare a subset of the attributes returned by the IFS_OBJECT_STATISTICS table function when an exact match is found on integrated file system path name and object type between the source and copy node.

If any of the attributes differ, the compare facility will return rows that show the attribute value on both nodes.

If the compare facility returns zero rows, there are no mismatches in object existence or compared attributes of objects that exist on both nodes.

Consider the following example, where every subdirectory and object within subdirectory under the starting path of ‘/home/’ is compared between the source and copy node. A CREATE OR REPLACE TABLE statement is used to establish a physical copy of any miscompare detail. This approach is useful because it allows any miscompare detail to be studied based upon a final report that can be examined multiple times.

CL: CRTLIB MIGIFS;

CREATE OR REPLACE TABLE MIGIFS.COMP_HOMES AS (
SELECT *
  FROM TABLE (
      QSYS2.COMPARE_IFS(
        START_PATH_NAME1     => '/home/', 
        START_PATH_NAME2     => '/home/',
        RDB2                 => 'QIBM_DB2M_00000', 
        OBJECT_TYPE_LIST     => '*ALL', 
        SUBTREE_DIRECTORIES  => 'YES',
        COMPARE_ATTRIBUTES   => 'YES')
    )
    ) WITH DATA ON REPLACE DELETE ROWS;

SELECT * FROM MIGIFS.COMP_HOMES;

Configuring integrated file system files or integrated file system trees to avoid migration

Migrate While Active uses save and restore technology for both the system migration of the integrated file system and the data synchronization of integrated file system changes made after the system migration stage. As such, the integrated file system on the copy node will not include any integrated file system objects or integrated file system subdirectories which have been configured to disallow save of the object.

The Change Attribute (CHGATR) CL command includes the ability to configure the Allow Save (*ALWSAV) attribute for objects in the integrated file system.

This means that integrated file system objects on the source node that have Allow Save set to NO will result in that object not being migrated to the copy node. Further, if the object is a directory, no object within the directory tree will be migrated to the copy node.

For example, the following configuration choice excludes the user4 directory and all objects within the user4 directory from integrated file system migration:

CHGATR OBJ('/home/user4') ATR(*ALWSAV) VALUE(*NO)

If the integrated file system object has the SYSTEM_RESTRICT_SAVE set to YES, the object is not migrated or synchronized by Migrate While Active. To understand the SYSTEM_RESTRICT_SAVE setting, use the IFS_OBJECT_STATISTICS table function.

--
-- Review integrated file system objects that have attributes that prevent them 
--   from being migrated
--
SELECT PATH_NAME, OBJECT_TYPE, SYMBOLIC_LINK, ALLOW_SAVE, SYSTEM_RESTRICT_SAVE
  FROM TABLE (
      QSYS2.IFS_OBJECT_STATISTICS('/home/', SUBTREE_DIRECTORIES => 'YES')
    )
  WHERE ALLOW_SAVE = 'NO' OR
        SYSTEM_RESTRICT_SAVE = 'YES';