• Dan Williams's avatar
    md: handle_stripe5 - add request/completion logic for async check ops · e89f8962
    Dan Williams authored
    Check operations are scheduled when the array is being resynced or an
    explicit 'check/repair' command was sent to the array.  Previously check
    operations would destroy the parity block in the cache such that even if
    parity turned out to be correct the parity block would be marked
    !R5_UPTODATE at the completion of the check.  When the operation can be
    carried out by a dma engine the assumption is that it can check parity as a
    read-only operation.  If raid5_run_ops notices that the check was handled
    by hardware it will preserve the R5_UPTODATE status of the parity disk.
    
    When a check operation determines that the parity needs to be repaired we
    reuse the existing compute block infrastructure to carry out the operation.
    Repair operations imply an immediate write back of the data, so to
    differentiate a repair from a normal compute operation the
    STRIPE_OP_MOD_REPAIR_PD flag is added.
    
    Changelog:
    * remove test_and_set/test_and_clear BUG_ONs, Neil Brown
    Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
    Acked-By: default avatarNeilBrown <neilb@suse.de>
    e89f8962
raid5.c 137 KB