• Lars Ellenberg's avatar
    drbd: resync should only lock out specific ranges · f5b90b6b
    Lars Ellenberg authored
    During resync, if we need to block some specific incoming write because
    of active resync requests to that same range, we potentially caused
    *all* new application writes (to "cold" activity log extents) to block
    until this one request has been processed.
    
    Improve the do_submit() logic to
     * grab all incoming requests to some "incoming" list
     * process this list
       - move aside requests that are blocked by resync
       - prepare activity log transactions,
       - commit transactions and submit corresponding requests
       - if there are remaining requests that only wait for
         activity log extents to become free, stop the fast path
         (mark activity log as "starving")
       - iterate until no more requests are waiting for the activity log,
         but all potentially remaining requests are only blocked by resync
     * only then grab new incoming requests
    
    That way, very busy IO on currently "hot" activity log extents cannot
    starve scattered IO to "cold" extents. And blocked-by-resync requests
    are processed once resync traffic on the affected region has ceased,
    without blocking anything else.
    
    The only blocking mode left is when we cannot start requests to "cold"
    extents because all currently "hot" extents are actually used.
    Signed-off-by: default avatarPhilipp Reisner <philipp.reisner@linbit.com>
    Signed-off-by: default avatarLars Ellenberg <lars.ellenberg@linbit.com>
    f5b90b6b
drbd_req.c 51.6 KB