Migration, coexistence and compatibility

To migrate to GPFS™ 4.1, first consider whether you are migrating from GPFS 3.5 or from an earlier release of GPFS, and then consider coexistence and compatibility issues.

GPFS supports a limited form of backward compatibility between two adjacent GPFS releases. Limited backward compatibility allows you to temporarily operate with a mixture of GPFS 4.1 and GPFS 3.5 nodes:
  • Within a cluster this enables you to perform a rolling upgrade to the new GPFS 4.1 version of the code provided your current version is GPFS 3.5.
  • In a multicluster environment this allows the individual clusters to be upgraded on their own schedules. Access to the file system data can be preserved even though some of the clusters may still be running GPFS 3.5 level.

Rolling upgrades allow you to install new GPFS code one node at a time without shutting down GPFS on other nodes. However, you must upgrade all nodes within a short time. The time dependency exists because some GPFS 4.1 features become available on each node as soon as the node is upgraded, while other features will not become available until you upgrade all participating nodes. Once all nodes have been migrated to the new code, you must finalize the migration by running the commands mmchconfig release=LATEST and mmchfs -V full (or mmchfs -V compat). Also, certain new features may require you to run the mmmigratefs command to enable them.

Attention: Starting with GPFS 4.1, a full backup (-t full) with mmbackup is required if a full backup has never been performed with GPFS 3.3 or later. For more information, see File systems backed up using GPFS 3.2 or earlier versions of mmbackup in IBM Spectrum Scale: Administration and Programming Reference.

For the latest information on migration, coexistence, and compatibility, see the IBM Spectrum Scale™ FAQ in IBM® Knowledge Center.

GPFS migration consists of these topics: