• NeilBrown's avatar
    md/raid5: ensure device failure recorded before write request returns. · c3cce6cd
    NeilBrown authored
    When a write to one of the devices of a RAID5/6 fails, the failure is
    recorded in the metadata of the other devices so that after a restart
    the data on the failed drive wont be trusted even if that drive seems
    to be working again (maybe a cable was unplugged).
    
    Similarly when we record a bad-block in response to a write failure,
    we must not let the write complete until the bad-block update is safe.
    
    Currently there is no interlock between the write request completing
    and the metadata update.  So it is possible that the write will
    complete, the app will confirm success in some way, and then the
    machine will crash before the metadata update completes.
    
    This is an extremely small hole for a racy to fit in, but it is
    theoretically possible and so should be closed.
    
    So:
     - set MD_CHANGE_PENDING when requesting a metadata update for a
       failed device, so we can know with certainty when it completes
     - queue requests that completed when MD_CHANGE_PENDING is set to
       only be processed after the metadata update completes
     - call raid_end_bio_io() on bios in that queue when the time comes.
    Signed-off-by: default avatarNeilBrown <neilb@suse.com>
    c3cce6cd
raid5.c 222 KB