[Bugs] [Bug 1293534] guest paused due to IO error from gluster based storage doesn't resume automatically or manually

bugzilla at redhat.com bugzilla at redhat.com
Tue Feb 16 09:13:50 UTC 2016


https://bugzilla.redhat.com/show_bug.cgi?id=1293534



--- Comment #9 from Vijay Bellur <vbellur at redhat.com> ---
COMMIT: http://review.gluster.org/13057 committed in release-3.7 by Raghavendra
G (rgowdapp at redhat.com) 
------
commit e424283c1f40386e5e3323b44df1a591ca62a7e8
Author: Raghavendra G <rgowdapp at redhat.com>
Date:   Tue Nov 17 12:57:54 2015 +0530

    performance/write-behind: retry "failed syncs to backend"

    1. When sync fails, the cached-write is still preserved unless there
       is a flush/fsync waiting on it.

    2. When a sync fails and there is a flush/fsync waiting on the
       cached-write, the cache is thrown away and no further retries will
       be made. In other words flush/fsync act as barriers for all the
       previous writes. The behaviour of fsync acting as a barrier is
       controlled by an option (see below for details). All previous
       writes are either successfully synced to backend or forgotten in
       case of an error. Without such barrier fop (especially flush which
       is issued prior to a close), we end up retrying for ever even after
       fd is closed.

    3. If a fop is waiting on cached-write and syncing to backend fails,
       the waiting fop is failed.

    4. sync failures when no fop is waiting are ignored and are not
       propagated to application. For eg.,
       a. first attempt of sync of a cached-write w1 fails
       b. second attempt of sync of w1 succeeds

       If there are no fops dependent on w1 are issued b/w a and b,
       application won't know about failure encountered in a.

    5. The effect of repeated sync failures is that, there will be no
       cache for future writes and they cannot be written behind.

    fsync as a barrier and resync of cached writes post fsync failure:
    ==================================================================
    Whether to keep retrying failed syncs post fsync is controlled by an
    option "resync-failed-syncs-after-fsync". By default, this option is
    set to "off".

    If sync of "cached-writes issued before fsync" (to backend) fails,
    this option configures whether to retry syncing them after fsync or
    forget them. If set to on, cached-writes are retried till a "flush"
    fop (or a successful sync) on sync failures. fsync itself is failed
    irrespective of the value of this option, when there is a sync failure
    of any cached-writes issued before fsync.

    Change-Id: I6097c0257bfb9ee5b1f616fbe6a0576ae9af369a
    Signed-off-by: Raghavendra G <rgowdapp at redhat.com>
    BUG: 1293534
    Signed-off-by: Raghavendra Talur <rtalur at redhat.com>
    Reviewed-on: http://review.gluster.org/13057
    Smoke: Gluster Build System <jenkins at build.gluster.com>
    NetBSD-regression: NetBSD Build System <jenkins at build.gluster.org>
    CentOS-regression: Gluster Build System <jenkins at build.gluster.com>

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=LWM3wuTWyy&a=cc_unsubscribe


More information about the Bugs mailing list