Procedure: Making drives support protection information

Edit online

You can use this procedure to migrate drives and arrays to pick up support for protection information.

About this task

Drives cannot start by using protection information for I/O requests on demand. They must be validated as having a correct format and general support for the function within the code. The system can validate the format and general support when the drive object is first discovered by the system. The requirement for system validation means that no drive that exists can use protection information on an update from version 730 regardless of use in the configuration. The system can reject a request to make a drive a candidate if the media is not formatted correctly for use with protection information. The process to use protection information on an existing drive is to use the system interface (GUI/CLI) and involves unmanaging and rediscovering the drive to allow the software to reacquire the drive characteristics.

The lsdrive view contains the protection_enabled field that shows whether a drive is using protection information. Drives and arrays that exist on an update to version 740 do not automatically pick up support for protection information. All newly discovered drives at this code level support protection information. If the system has spare capacity, then migration can proceed an MDisk at a time. Otherwise, the migration to using protection information on drives proceeds drive by drive.

To migrate a MDisk that is using spare storage capacity, complete the following procedure.

Procedure

  1. Migrate data off the MDisk.
    The data migration can be accomplished by MDisk migration as part of MDisk delete (rmmdisk, lsmigrate) within a storage pool. You can also use volume mirroring to create an in-sync mirrored copy of each volume in another pool (addvdiskcopy). When it is copied (lsvdisksyncprogress), delete the original volume copies (rmvdiskcopy), and then delete the MDisk (rmmdisk) that has no data.
  2. Follow the instructions in step 5 for all the drives that are now candidates when the MDisk is deleted (see lsmigrate).
  3. Re-create the array by using the system interface when all old members adopt protection information.
  4. If the drive is a member, complete the following steps to adopt protection information on an individual drive.
    1. Run the charraymember command to eject the drive from the array (either immediately with redundancy loss or after an exchange).
    2. When the drive is no longer a member, follow the instructions in step 5 for candidates or spares.
    3. Repeat for the next member.
  5. If the drive is a spare or candidate, complete the following steps:
    1. Use the management GUI to take the drive offline.
    2. When the drive is offline, use the system interfaces to change the drive's use to unused.
    3. The system reacquires the drive and brings it back online, possibly changing the drive ID.
    4. Attempt to make the drive a candidate.

      Depending on the drive, this step might generate error CMMVC6624E, The command cannot be initiated because the drive is not in an appropriate state to perform the task. This step is necessary to run the format command in the next step.

    5. Run the following format command.

      svctask chdrive -task format drive_id

    6. Wait approximately 3 minutes until the drive is online again.
      Use lsdrive drive_id to see the drive's online/offline status.
    7. Use the system interface to change the drive's use to candidate. If required, use the system interface to change the drive's use to spare.
    8. Enter lsdrive drive_id and check that the protection_enabled field is yes. This drive can now be used in an array.