IBM Support

IJ25687: OFFLINE FSCK REPORTS FALSE POSITIVE DUPLICATEDISKADDR CORRUPTIONS BETWEEN SNAPSHOTS

Subscribe to this APAR

By subscribing, you receive periodic emails alerting you to the status of the APAR, along with a link to the fix after it becomes available. You can track this item individually or track all items by product.

Notify me when this APAR changes.

Notify me when an APAR for this component changes.

 

APAR status

  • Closed as program error.

Error description

  • When a snapshot gets deleted some of the blocks of the
    snapshot are copied to the previous snapshot to maintain
    data and metadata consistency. Now if due to some reason
    when the deletion of the snapshot is interrupted we can have
    a scenario where the blocks are
    copied to the previous snapshot
    but the block disk addresses are not
    yet removed from the snapshot
    being deleted, the status of such
    snapshots change to DeleteRequired.
    This condition is expected for
    DeletedRequired snapshots and will be
    handled properly when the deletion of the snapshot is retried.
    But if before deleting the DeleteRequired
    snapshot if an offline fsck is
    run on the file system then fsck will
    falsely report such blocks as
    duplicate address between the
    DeleteRequired snapshot and its
    previous snapshots.
    

Local fix

  • Complete deletion of all the DeleteRequired status
    snapshots before running offline fsck
    

Problem summary

  • When a snapshot gets deleted some of the blocks of the
    snapshot are copied to the previous snapshot to maintain
    data and metadata consistency. Now if due to some reason
    when the deletion of the snapshot is interrupted we can have
    a scenario where the blocks are
    copied to the previous snapshot
    but the block disk addresses are not
    yet removed from the snapshot
    being deleted, the status of such
    snapshots change to DeleteRequired.
    This condition is expected for
    DeletedRequired snapshots and will be
    handled properly when the deletion of the snapshot is retried.
    But if before deleting the DeleteRequired
    snapshot if an offline fsck is
    run on the file system then fsck will
    falsely report such blocks as
    duplicate address between the
    DeleteRequired snapshot and its
    previous snapshots.
    

Problem conclusion

  • Benefits of the solution:
    With this solution offline fsck will not report false positive
    duplicate address blocks in the snaphots
    Work around:
    Complete deletion of all the DeleteRequired status
    snapshots before running offline fsck
    Problem trigger:
    This issue can occur when the delete of a snapshot has been
    interrupted due to some reason causing the snapshot to now
    show status of DeleteRequired and then offline fsck is run on
    the file system before deleting the DeleteRequired snapshot.
    Symptom:
    Incorrect report of corruptions by fsck
    Platforms affected:
    ALL Operating System environments
    Functional Area affected:
    FSCK
    Customer Impact:
    High Importance
    

Temporary fix

Comments

APAR Information

  • APAR number

    IJ25687

  • Reported component name

    SPEC SCALE STD

  • Reported component ID

    5737F33AP

  • Reported release

    505

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2020-06-19

  • Closed date

    2020-06-19

  • Last modified date

    2020-06-19

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

    IJ27813

Fix information

  • Fixed component name

    SPEC SCALE STD

  • Fixed component ID

    5737F33AP

Applicable component levels

[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"STXKQY","label":"IBM Spectrum Scale"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"505","Line of Business":{"code":"LOB26","label":"Storage"}}]

Document Information

Modified date:
15 September 2020