On 04/19/2016 08:07 AM, Jeff Cody wrote:
Bug fixes for gluster; third patch is to prevent
a potential data loss when trying to recover from
a recoverable error (such as ENOSPC).
Hi Jeff,
Just a note, I have been talking to some of the disk drive people here at LSF
(the kernel summit for file and storage people) and got a non-public
confirmation that individual storage devices (s-ata drives or scsi) can also
dump cache state when a synchronize cache command fails. Also followed up with
Rik van Riel - in the page cache in general, when we fail to write back dirty
pages, they are simply marked "clean" (which means effectively that they get
dropped).
Long winded way of saying that I think that this scenario is not unique to
gluster - any failed fsync() to a file (or block device) might be an indication
of permanent data loss.
Regards,
Ric
The final patch closes the gluster fd and sets the
protocol drv to NULL on fsync failure in gluster;
we have no way of knowing what gluster versions
support retaining fysnc cache on error, so until
we do the safest thing to do is invalidate the
drive.
Jeff Cody (3):
block/gluster: return correct error value
block/gluster: code movement of qemu_gluster_close()
block/gluster: prevent data loss after i/o error
block/gluster.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++-----------
configure | 8 +++++++
2 files changed, 62 insertions(+), 12 deletions(-)
