Bug 1361513 - EC: Set/unset dirty flag for all the update operations
Summary: EC: Set/unset dirty flag for all the update operations
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat Storage
Component: disperse
Version: rhgs-3.1
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: RHGS 3.2.0
Assignee: Ashish Pandey
QA Contact: Nag Pavan Chilakam
URL:
Whiteboard:
: 1367779 (view as bug list)
Depends On: 1316873 1377570
Blocks: 1351522
TreeView+ depends on / blocked
 
Reported: 2016-07-29 09:14 UTC by Pranith Kumar K
Modified: 2017-03-23 05:43 UTC (History)
9 users (show)

Fixed In Version: glusterfs-3.8.4-3
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1316873
Environment:
Last Closed: 2017-03-23 05:43:29 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2017:0486 0 normal SHIPPED_LIVE Moderate: Red Hat Gluster Storage 3.2.0 security, bug fix, and enhancement update 2017-03-23 09:18:45 UTC

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


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