Bug 1559788

Summary: Remove use-compound-fops feature
Product: [Red Hat Storage] Red Hat Gluster Storage Reporter: Pranith Kumar K <pkarampu>
Component: replicateAssignee: Pranith Kumar K <pkarampu>
Status: CLOSED ERRATA QA Contact: Vijay Avuthu <vavuthu>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rhgs-3.4CC: asriram, pkarampu, rhs-bugs, storage-qa-internal, vdas
Target Milestone: ---   
Target Release: RHGS 3.4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: glusterfs-3.12.2-6 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-09-04 06:45:40 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1503137    

Description Pranith Kumar K 2018-03-23 09:32:43 UTC
Description of problem:
History:
Compound fops option is added at the time of RHGS 3.2.0 even though the performance improvements are not visible on the assumption that we can do incremental effort to improve performance in future releases.  You can find the details of the performance analysis done at the time of RHGS-3.2.0 @ https://mojo.redhat.com/docs/DOC-1124201

What is the reason behind removing at this point?
Why can't we just keep the code and disable it?

AFR transaction logic already is complex enough. Maintaining two ways of doing transactions is adding to maintenance burden. Every change we have to do needs to be thought out for compound-fops on/off. It would have been a fruitful effort had it given significant boost to the iops. For 3.4.0 we are changing eager-lock so that it can give better iops for both RHHI/gluster-block workloads. Implementing that change with compound-fops is a bit involved and after this release, Karthik is going to implement more changes to the transaction, which also need to be thoughtout for compound-fops if this feature is present. So looking at all this, it looks like we are spending more effort without any potential benefit to the user. It would make things faster for both DEV and QE if we don't have to test each change in transaction twice. Thus we are removing this functionality.

Will the option be removed?
What will happen to the customers who already enabled it?

The option needs to stay as a dummy for allowing upgrades without any issues. It will be integrated into Nitya's effort to disable some of the options in future.
Customers who enabled it by default, wouldn't have gained much as per our perf results. So disabling it wouldn't lead to any change in user experience.

The only thing that needs a guidance from PM for this is: What should we do with the documentation of the option?

What is the QE feature test effort for this change?
This option is disabled by default. So whatever the QE needs to test as part of regression testing is enough to validate the change. So there is no extra effort.

What is the DEV effort?
Patches are already posted upstream. We were waiting for more comments in the upstream but I am inclined to merge the patch in the morning once I get reviews upstream from Ravi/Karthik


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 3 Pranith Kumar K 2018-03-23 11:14:08 UTC
https://code.engineering.redhat.com/gerrit/131943

Comment 8 Vijay Avuthu 2018-08-23 13:12:12 UTC
Update:
=========

Build used: glusterfs-3.12.2-16.el7rhgs.x86_64

> By default use-compound-fops is disabled by default

# gluster vol get 23 cluster.use-compound-fops
Option                                  Value                                   
------                                  -----                                   
cluster.use-compound-fops               off                                     
# 

> Didn't see any regression issue induced with this option ( disabled by default).

Changing status to Verified

Comment 10 errata-xmlrpc 2018-09-04 06:45:40 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:2607