Skip to content
  • Jeff Cody's avatar
    d85fa9eb
    block/gluster: prevent data loss after i/o error · d85fa9eb
    Jeff Cody authored
    
    
    Upon receiving an I/O error after an fsync, by default gluster will
    dump its cache.  However, QEMU will retry the fsync, which is especially
    useful when encountering errors such as ENOSPC when using the werror=stop
    option.  When using caching with gluster, however, the last written data
    will be lost upon encountering ENOSPC.  Using the write-behind-cache
    xlator option of 'resync-failed-syncs-after-fsync' should cause gluster
    to retain the cached data after a failed fsync, so that ENOSPC and other
    transient errors are recoverable.
    
    Unfortunately, we have no way of knowing if the
    'resync-failed-syncs-after-fsync' xlator option is supported, so for now
    close the fd and set the BDS driver to NULL upon fsync error.
    
    Signed-off-by: default avatarJeff Cody <jcody@redhat.com>
    d85fa9eb
    block/gluster: prevent data loss after i/o error
    Jeff Cody authored
    
    
    Upon receiving an I/O error after an fsync, by default gluster will
    dump its cache.  However, QEMU will retry the fsync, which is especially
    useful when encountering errors such as ENOSPC when using the werror=stop
    option.  When using caching with gluster, however, the last written data
    will be lost upon encountering ENOSPC.  Using the write-behind-cache
    xlator option of 'resync-failed-syncs-after-fsync' should cause gluster
    to retain the cached data after a failed fsync, so that ENOSPC and other
    transient errors are recoverable.
    
    Unfortunately, we have no way of knowing if the
    'resync-failed-syncs-after-fsync' xlator option is supported, so for now
    close the fd and set the BDS driver to NULL upon fsync error.
    
    Signed-off-by: default avatarJeff Cody <jcody@redhat.com>
Loading