Topic
  • 9 replies
  • Latest Post - ‏2012-08-15T20:01:13Z by dlmcnabb
gpfs@us.ibm.com
gpfs@us.ibm.com
223 Posts

Pinned topic An issue using the --fastea option on mmmigratefs command requires a fix

‏2012-07-04T10:31:24Z |
IBM has identified an issue with GPFS file systems at versions 3.4 or 3.5 which were migrated
from file systems created with GPFS versions earlier than 3.4. This issue can occur only
after using the mmmigratefs command with the --fastea option.

The issue can result in a loss of data, requiring the restoration of data from a backup source.

GPFS file systems created with versions earlier than 3.4 should not be migrated using the
mmmigratefs command with the --fastea option until a fix is provided from IBM. IBM plans
to make the fix available in GPFS versions 3.5.0.3 (APAR IV24151) and 3.4.0.15 (APAR IV24150).
An ifix will also be available from IBM Service.

If customers have already migrated file systems from GPFS versions earlier than 3.4, IBM Service
has a fix. Please follow the steps below to determine if your system may be affected.

To determine if your system may be affected:

1. Ensure your GPFS file systems are mounted.

2. As a user with GPFS administrator privileges on a machine where your GPFS file systems are
mounted, issue the command:

/usr/lpp/mmfs/bin/mmfsadm dump stripe | grep "inode 0"

The command will produce output that identifies locations for the "inode 0" file for all
currently mounted GPFS file systems. Example output for a file system configured with two
way metadata replication would be in the form:

inode 0: 3:4098 1:4098

For a file system with no metadata replication the output would be in the form:

inode 0: 3:4098

The relevant information to look for to see if you may experience a problem are the fields
denoting <disk>:<sector> for each inode 0 replica (e.g. 3:4098 and 1:4098 in these examples).

If each <disk>:<sector> replica only denotes 4098 for the sector field then you are not
experiencing this problem. If however there is a number other than 4098 in the sector output
then you are requested to immediately call IBM Service and reference this problem.
The IBM
Service person will walk you thru a fix for correcting the issue.

Edited by: puneetc on Jul 4, 2012 10:56 PM

Edited by: puneetc on Jul 4, 2012 10:58 PM
Updated on 2012-08-15T20:01:13Z at 2012-08-15T20:01:13Z by dlmcnabb
  • dlmcnabb
    dlmcnabb
    8 Posts

    Re: An issue using the --fastea option on mmmigratefs command requires a fix

    ‏2012-07-09T20:26:32Z  
    Here is a shell script that will check all filesystems as to whether they need to have work done on them.
  • dlmcnabb
    dlmcnabb
    8 Posts

    Re: An issue using the --fastea option on mmmigratefs command requires a fix

    ‏2012-07-11T18:45:49Z  
    • dlmcnabb
    • ‏2012-07-09T20:26:32Z
    Here is a shell script that will check all filesystems as to whether they need to have work done on them.
    Here is a newer verion of the test script. It fixes a problem where some operating systems return "Yes" instead of "yes" on the mmlsfs internal request.

    Also, if there are problems that needs fixing, it gathers mmdf, mmlsfs, and mmlsnsd -F to aid in giving advice for fixup.
  • dlmcnabb
    dlmcnabb
    8 Posts

    Re: An issue using the --fastea option on mmmigratefs command requires a fix

    ‏2012-07-12T23:38:43Z  
    • dlmcnabb
    • ‏2012-07-11T18:45:49Z
    Here is a newer verion of the test script. It fixes a problem where some operating systems return "Yes" instead of "yes" on the mmlsfs internal request.

    Also, if there are problems that needs fixing, it gathers mmdf, mmlsfs, and mmlsnsd -F to aid in giving advice for fixup.
    (Man who writes this buggy code;) Another fix. When the filesystem does not have replicated metadata and inode 0 is in the correct sector 4098, the wrong message is displayed.
  • chr78
    chr78
    1 Post

    Re: An issue using the --fastea option on mmmigratefs command requires a fix

    ‏2012-07-13T07:59:47Z  
    • dlmcnabb
    • ‏2012-07-12T23:38:43Z
    (Man who writes this buggy code;) Another fix. When the filesystem does not have replicated metadata and inode 0 is in the correct sector 4098, the wrong message is displayed.
    this script seems to have carriage returns (^M) inside and thus won't work out of the box ;)
  • dlmcnabb
    dlmcnabb
    8 Posts

    Re: An issue using the --fastea option on mmmigratefs command requires a fix

    ‏2012-07-13T09:55:05Z  
    • chr78
    • ‏2012-07-13T07:59:47Z
    this script seems to have carriage returns (^M) inside and thus won't work out of the box ;)
    Try this oece again to get out the linefeeds.
  • dlmcnabb
    dlmcnabb
    8 Posts

    Re: An issue using the --fastea option on mmmigratefs command requires a fix

    ‏2012-07-23T20:29:51Z  
    • dlmcnabb
    • ‏2012-07-13T09:55:05Z
    Try this oece again to get out the linefeeds.
    Here is a newer testfilesystems script that is a bit safer than the previous one. Some older code versions of GPFS would crash the FS manager node when trying to format an inode that may be corrupted.
  • dlmcnabb
    dlmcnabb
    8 Posts

    Re: An issue using the --fastea option on mmmigratefs command requires a fix

    ‏2012-07-23T20:30:09Z  
    • dlmcnabb
    • ‏2012-07-23T20:29:51Z
    Here is a newer testfilesystems script that is a bit safer than the previous one. Some older code versions of GPFS would crash the FS manager node when trying to format an inode that may be corrupted.
    Forgot attachment.
  • dlmcnabb
    dlmcnabb
    8 Posts

    Re: An issue using the --fastea option on mmmigratefs command requires a fix

    ‏2012-07-23T20:30:41Z  
    • dlmcnabb
    • ‏2012-07-23T20:29:51Z
    Here is a newer testfilesystems script that is a bit safer than the previous one. Some older code versions of GPFS would crash the FS manager node when trying to format an inode that may be corrupted.
    Forgot attachment.
  • dlmcnabb
    dlmcnabb
    8 Posts

    Re: An issue using the --fastea option on mmmigratefs command requires a fix

    ‏2012-08-15T20:01:13Z  
    • dlmcnabb
    • ‏2012-07-23T20:30:41Z
    Forgot attachment.
    Here is version 3.4 of testfilesystems. Old one was returning false messages about corruption, due to error in checksum algorithm.