• NeilBrown's avatar
    md/raid5: fix interaction of 'replace' and 'recovery'. · f94c0b66
    NeilBrown authored
    If a device in a RAID4/5/6 is being replaced while another is being
    recovered, then the writes to the replacement device currently don't
    happen, resulting in corruption when the replacement completes and the
    new drive takes over.
    
    This is because the replacement writes are only triggered when
    's.replacing' is set and not when the similar 's.sync' is set (which
    is the case during resync and recovery - it means all devices need to
    be read).
    
    So schedule those writes when s.replacing is set as well.
    
    In this case we cannot use "STRIPE_INSYNC" to record that the
    replacement has happened as that is needed for recording that any
    parity calculation is complete.  So introduce STRIPE_REPLACED to
    record if the replacement has happened.
    
    For safety we should also check that STRIPE_COMPUTE_RUN is not set.
    This has a similar effect to the "s.locked == 0" test.  The latter
    ensure that now IO has been flagged but not started.  The former
    checks if any parity calculation has been flagged by not started.
    We must wait for both of these to complete before triggering the
    'replace'.
    
    Add a similar test to the subsequent check for "are we finished yet".
    This possibly isn't needed (is subsumed in the STRIPE_INSYNC test),
    but it makes it more obvious that the REPLACE will happen before we
    think we are finished.
    
    Finally if a NeedReplace device is not UPTODATE then that is an
    error.  We really must trigger a warning.
    
    This bug was introduced in commit 9a3e1101
    (md/raid5:  detect and handle replacements during recovery.)
    which introduced replacement for raid5.
    That was in 3.3-rc3, so any stable kernel since then would benefit
    from this fix.
    
    Cc: stable@vger.kernel.org (3.3+)
    Reported-by: default avatarqindehua <13691222965@163.com>
    Tested-by: default avatarqindehua <qindehua@163.com>
    Signed-off-by: default avatarNeilBrown <neilb@suse.de>
    f94c0b66
raid5.c 182 KB