• NeilBrown's avatar
    md: support barrier requests on all personalities. · a2826aa9
    NeilBrown authored
    Previously barriers were only supported on RAID1.  This is because
    other levels requires synchronisation across all devices and so needed
    a different approach.
    Here is that approach.
    
    When a barrier arrives, we send a zero-length barrier to every active
    device.  When that completes - and if the original request was not
    empty -  we submit the barrier request itself (with the barrier flag
    cleared) and then submit a fresh load of zero length barriers.
    
    The barrier request itself is asynchronous, but any subsequent
    request will block until the barrier completes.
    
    The reason for clearing the barrier flag is that a barrier request is
    allowed to fail.  If we pass a non-empty barrier through a striping
    raid level it is conceivable that part of it could succeed and part
    could fail.  That would be way too hard to deal with.
    So if the first run of zero length barriers succeed, we assume all is
    sufficiently well that we send the request and ignore errors in the
    second run of barriers.
    
    RAID5 needs extra care as write requests may not have been submitted
    to the underlying devices yet.  So we flush the stripe cache before
    proceeding with the barrier.
    
    Note that the second set of zero-length barriers are submitted
    immediately after the original request is submitted.  Thus when
    a personality finds mddev->barrier to be set during make_request,
    it should not return from make_request until the corresponding
    per-device request(s) have been queued.
    
    That will be done in later patches.
    Signed-off-by: default avatarNeilBrown <neilb@suse.de>
    Reviewed-by: default avatarAndre Noll <maan@systemlinux.org>
    a2826aa9
multipath.c 14.8 KB