Bug 1333142 - Provide way to determine if xlator option 'resync-failed-syncs-after-fsync' is supported
Summary: Provide way to determine if xlator option 'resync-failed-syncs-after-fsync' i...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat Storage
Component: write-behind
Version: unspecified
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: ---
: ---
Assignee: Csaba Henk
QA Contact: Rahul Hinduja
URL:
Whiteboard:
Depends On: 1333358
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-05-04 18:41 UTC by Jeff Cody
Modified: 2018-04-16 18:18 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-16 18:18:23 UTC
Embargoed:


Attachments (Terms of Use)

Description Jeff Cody 2016-05-04 18:41:08 UTC
In the current upstream Gluster, the write-behind cache supports a xlator option 'resync-failed-syncs-after-fsync', which has Gluster retain the cache on fsync failure, until the file descriptor is flushed/closed.  With this QEMU, when using the libglusterfs library, can perform retries on a fsync failure.

However, QEMU has no way of determining at runtime if this xlator option is supported.  The api glfs_set_xlator_option() will return success even for unknown options.  It would be very useful for us to be able to determine if we can use the new xlator option - until we can determine if it is support, QEMU must act as if it is not supported.

Comment 4 Csaba Henk 2018-03-05 13:41:44 UTC
This will be addressed by upstream enhancement https://github.com/gluster/glusterfs/issues/263 in a more general context.


Note You need to log in before you can comment on or make changes to this bug.