Bug 1361513

Summary:	EC: Set/unset dirty flag for all the update operations
Product:	[Red Hat Storage] Red Hat Gluster Storage	Reporter:	Pranith Kumar K <pkarampu>
Component:	disperse	Assignee:	Ashish Pandey <aspandey>
Status:	CLOSED ERRATA	QA Contact:	Nag Pavan Chilakam <nchilaka>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rhgs-3.1	CC:	amukherj, aspandey, bugs, hgowtham, nchilaka, pkarampu, rcyriac, rhinduja, rhs-bugs
Target Milestone:	---	Keywords:	Triaged
Target Release:	RHGS 3.2.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	glusterfs-3.8.4-3	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	1316873	Environment:
Last Closed:	2017-03-23 05:43:29 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:	1316873, 1377570
Bug Blocks:	1351522

Description Pranith Kumar K 2016-07-29 09:14:48 UTC

+++ This bug was initially created as a clone of Bug #1316873 +++

Description of problem:

Set/unset dirty flag for all the update operations

If write operation come for a file, set its the dirty flag in preop for that file, perform write and then unset dirty flag in post of if write is successful on all the bricks. 
If any brick goes down during write fop, keep the dirty flag ON and don't unset it in postop. This will trigger heal for the file when the bricks comes up.

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


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

--- Additional comment from Vijay Bellur on 2016-03-15 03:26:03 EDT ---

REVIEW: http://review.gluster.org/13733 (cluster/ec: set/unset dirty flag for data/metadata update) posted (#1) for review on master by Ashish Pandey (aspandey)

--- Additional comment from Vijay Bellur on 2016-03-16 02:48:54 EDT ---

REVIEW: http://review.gluster.org/13733 (cluster/ec: set/unset dirty flag for data/metadata update) posted (#2) for review on master by Ashish Pandey (aspandey)

--- Additional comment from Vijay Bellur on 2016-03-21 01:45:56 EDT ---

REVIEW: http://review.gluster.org/13733 (cluster/ec: set/unset dirty flag for data/metadata update) posted (#3) for review on master by Ashish Pandey (aspandey)

--- Additional comment from Vijay Bellur on 2016-03-21 02:24:13 EDT ---

REVIEW: http://review.gluster.org/13733 (cluster/ec: set/unset dirty flag for data/metadata update) posted (#4) for review on master by Ashish Pandey (aspandey)

--- Additional comment from Vijay Bellur on 2016-03-21 05:40:30 EDT ---

REVIEW: http://review.gluster.org/13733 (cluster/ec: set/unset dirty flag for data/metadata update) posted (#5) for review on master by Ashish Pandey (aspandey)

--- Additional comment from Mike McCune on 2016-03-28 18:17:27 EDT ---

This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

--- Additional comment from Vijay Bellur on 2016-04-04 04:13:13 EDT ---

REVIEW: http://review.gluster.org/13733 (cluster/ec: set/unset dirty flag for data/metadata update) posted (#6) for review on master by Ashish Pandey (aspandey)

--- Additional comment from Vijay Bellur on 2016-04-12 13:55:49 EDT ---

REVIEW: http://review.gluster.org/13733 (cluster/ec: set/unset dirty flag for data/metadata update) posted (#7) for review on master by Ashish Pandey (aspandey)

--- Additional comment from Vijay Bellur on 2016-04-19 16:41:28 EDT ---

REVIEW: http://review.gluster.org/13733 (cluster/ec: set/unset dirty flag for data/metadata update) posted (#8) for review on master by Ashish Pandey (aspandey)

Comment 3 Atin Mukherjee 2016-08-30 05:30:28 UTC

http://review.gluster.org/#/c/13733/ posted upstream for review.

Comment 4 Pranith Kumar K 2016-08-31 21:36:37 UTC

*** Bug 1367779 has been marked as a duplicate of this bug. ***

Comment 7 Nag Pavan Chilakam 2016-12-22 13:50:35 UTC

currently unable to validate due to regression in perf, which seems to be because of this fix

Comment 8 Nag Pavan Chilakam 2017-02-09 06:11:26 UTC

(In reply to nchilaka from comment #7)
> currently unable to validate due to regression in perf, which seems to be
> because of this fix

Is this problem solved?
Is the perf regression is still existing because of this fix?

Comment 10 Nag Pavan Chilakam 2017-02-27 14:21:52 UTC

I tested this fix with and without eager lock.
I see the setting of dirty bits before and after op in both below cases:
1)all bricks up
2) one brick down


hence moving to verified
test version:
3.8.4-15


note that i raised a bug while verifying this one Bug 1427159] New: possible repeatedly recursive healing of same file with background heal not happening when IO is going on

I confirmed with dev, that the above mentioned bug was not due to this fix

Comment 12 errata-xmlrpc 2017-03-23 05:43:29 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://rhn.redhat.com/errata/RHSA-2017-0486.html