Bug 988642 - quota: hitting "D" state for dd command
Summary: quota: hitting "D" state for dd command
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: GlusterFS
Classification: Community
Component: write-behind
Version: mainline
Hardware: x86_64
OS: All
unspecified
high
Target Milestone: ---
Assignee: Raghavendra G
QA Contact:
URL:
Whiteboard:
Depends On: 982629
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-07-26 03:44 UTC by Raghavendra G
Modified: 2014-04-17 11:44 UTC (History)
6 users (show)

Fixed In Version: glusterfs-3.5.0
Doc Type: Bug Fix
Doc Text:
Clone Of: 982629
Environment:
Last Closed: 2014-04-17 11:44:22 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)

Comment 1 Anand Avati 2013-07-26 03:45:57 UTC
REVIEW: http://review.gluster.org/5398 (performance/write-behind: invoke request queue processing more accurately.) posted (#1) for review on master by Raghavendra G (rgowdapp)

Comment 2 Anand Avati 2013-07-29 06:58:23 UTC
REVIEW: http://review.gluster.org/5398 (performance/write-behind: invoke request queue processing if we find fd marked bad while trying to fulfill lies.) posted (#2) for review on master by Raghavendra G (rgowdapp)

Comment 3 Anand Avati 2013-07-29 06:59:53 UTC
REVIEW: http://review.gluster.org/5398 (performance/write-behind: invoke request queue processing if we find fd marked bad while trying to fulfill lies.) posted (#3) for review on master by Raghavendra G (rgowdapp)

Comment 4 Anand Avati 2013-07-29 18:19:32 UTC
REVIEW: http://review.gluster.org/5398 (performance/write-behind: invoke request queue processing if we find fd marked bad while trying to fulfill lies.) posted (#4) for review on master by Raghavendra G (rgowdapp)

Comment 5 Anand Avati 2013-07-29 18:20:41 UTC
REVIEW: http://review.gluster.org/5398 (performance/write-behind: invoke request queue processing if we find fd marked bad while trying to fulfill lies.) posted (#5) for review on master by Raghavendra G (rgowdapp)

Comment 6 Anand Avati 2013-08-06 04:05:13 UTC
REVIEW: http://review.gluster.org/5398 (performance/write-behind: invoke request queue processing if we find fd marked bad while trying to fulfill lies.) posted (#6) for review on master by Raghavendra G (rgowdapp)

Comment 7 Anand Avati 2013-08-07 03:28:03 UTC
REVIEW: http://review.gluster.org/5398 (performance/write-behind: invoke request queue processing if we find fd marked bad while trying to fulfill lies.) posted (#7) for review on master by Raghavendra G (rgowdapp)

Comment 8 Anand Avati 2013-08-07 03:28:51 UTC
REVIEW: http://review.gluster.org/5398 (performance/write-behind: invoke request queue processing if we find fd marked bad while trying to fulfill lies.) posted (#8) for review on master by Raghavendra G (rgowdapp)

Comment 9 Anand Avati 2013-08-07 03:29:20 UTC
REVIEW: http://review.gluster.org/5398 (performance/write-behind: invoke request queue processing if we find fd marked bad while trying to fulfill lies.) posted (#9) for review on master by Raghavendra G (rgowdapp)

Comment 10 Anand Avati 2013-08-14 09:12:38 UTC
COMMIT: http://review.gluster.org/5398 committed in master by Anand Avati (avati) 
------
commit 1e49b3ac9b1019c742236be8db0ca8ec00750ae7
Author: Raghavendra G <rgowdapp>
Date:   Mon Jul 29 23:43:51 2013 +0530

    performance/write-behind: invoke request queue processing if
    we find fd marked bad while trying to fulfill lies.
    
    * flush was queued behind some unfulfilled write.
    * A previously wound write returned an error and hence fd was marked
      bad with corresponding error.
    * wb_fulfill_head (invocation probably rooted in wb_flush), before
      winding checks for failures of previous writes and since there was a
      failure, calls wb_head_done without even winding one request in head.
    * wb_head_done unrefs all the requests in list "head".
    * since flush was last operation on fd (and most likely last operation
      on inode itself), no one invokes wb_process_queue and flush is stuck
      in request queue for eternity.
    
    Change-Id: I3b5b114a1c401d477dd7ff64fb6119b43fda2d18
    BUG: 988642
    Signed-off-by: Raghavendra G <rgowdapp>
    Reviewed-on: http://review.gluster.org/5398
    Tested-by: Gluster Build System <jenkins.com>
    Reviewed-by: Anand Avati <avati>

Comment 11 Anand Avati 2013-09-10 00:56:09 UTC
REVIEW: http://review.gluster.org/5883 (performance/write-behind: invoke request queue processing if we find fd marked bad while trying to fulfill lies.) posted (#1) for review on release-3.4 by Anand Avati (avati)

Comment 12 Anand Avati 2013-09-10 01:08:36 UTC
REVIEW: http://review.gluster.org/5883 (performance/write-behind: invoke request queue processing if we find fd marked bad while trying to fulfill lies.) posted (#2) for review on release-3.4 by Anand Avati (avati)

Comment 13 Anand Avati 2013-09-10 08:25:26 UTC
COMMIT: http://review.gluster.org/5883 committed in release-3.4 by Vijay Bellur (vbellur) 
------
commit 8641a8641c4efec9cc7ac20108f2461a0300d01c
Author: Raghavendra G <rgowdapp>
Date:   Mon Jul 29 23:43:51 2013 +0530

    performance/write-behind: invoke request queue processing if
    we find fd marked bad while trying to fulfill lies.
    
    * flush was queued behind some unfulfilled write.
    * A previously wound write returned an error and hence fd was marked
      bad with corresponding error.
    * wb_fulfill_head (invocation probably rooted in wb_flush), before
      winding checks for failures of previous writes and since there was a
      failure, calls wb_head_done without even winding one request in head.
    * wb_head_done unrefs all the requests in list "head".
    * since flush was last operation on fd (and most likely last operation
      on inode itself), no one invokes wb_process_queue and flush is stuck
      in request queue for eternity.
    
    Change-Id: I3b5b114a1c401d477dd7ff64fb6119b43fda2d18
    BUG: 988642
    Signed-off-by: Raghavendra G <rgowdapp>
    Reviewed-on: http://review.gluster.org/5883
    Tested-by: Gluster Build System <jenkins.com>

Comment 14 Niels de Vos 2014-04-17 11:44:22 UTC
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.5.0, please reopen this bug report.

glusterfs-3.5.0 has been announced on the Gluster Developers mailinglist [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/6137
[2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user


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