• Heinz Mauelshagen's avatar
    dm raid: fix data corruption on reshape request · 4517ad77
    Heinz Mauelshagen authored
    commit d36a1954 upstream.
    
    The lvm2 sequence to manage dm-raid constructor flags that trigger a
    rebuild or a reshape is defined as:
    
    1) load table with flags (e.g. rebuild/delta_disks/data_offset)
    2) clear out the flags in lvm2 metadata
    3) store the lvm2 metadata, reload the table to reset the flags
       previously established during the initial load (1) -- in order to
       prevent repeatedly requesting a rebuild or a reshape on activation
    
    Currently, loading an inactive table with rebuild/reshape flags
    specified will cause dm-raid to rebuild/reshape on resume and thus start
    updating the raid metadata (about the progress).  When the second table
    reload, to reset the flags, occurs the constructor accesses the volatile
    progress state kept in the raid superblocks.  Because the active mapping
    is still processing the rebuild/reshape, that position will be stale by
    the time the device is resumed.
    
    In the reshape case, this causes data corruption by processing already
    reshaped stripes again.  In the rebuild case, it does _not_ cause data
    corruption but instead involves superfluous rebuilds.
    
    Fix by keeping the raid set frozen during the first resume and then
    allow the rebuild/reshape during the second resume.
    
    Fixes: 9dbd1aa3 ("dm raid: add reshaping support to the target")
    Signed-off-by: default avatarHeinz Mauelshagen <heinzm@redhat.com>
    Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
    Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    4517ad77
dm-raid.c 105 KB