Description of problem: When dealing with very busy clients and volumes, returning an offline brick to service may cause blocking, interrupting business for unacceptable periods of time. How reproducible: Always Steps to Reproduce: 1. Have a replicated volume with thousands of files (make them 100Mb files just for easy observation) being accessed and updated every minute. 2. Remove a brick from service for 1 hour. 3. Return that brick to service. Actual results: After 16 files are accessed through the client mount, the 17th file access will hang until that 17th file is healed. Expected results: An option should be added which would allow the client to continue to use the clean copy of the file without backgrounding a self-heal or blocking. Treat the file as if the formerly offline brick was still offline and allow either the self-heal daemon to heal it, or the next access if the background-self-heal queue is no longer full.
GlusterFS 3.7.0 has been released (http://www.gluster.org/pipermail/gluster-users/2015-May/021901.html), and the Gluster project maintains N-2 supported releases. The last two releases before 3.7 are still maintained, at the moment these are 3.6 and 3.5. This bug has been filed against the 3,4 release, and will not get fixed in a 3.4 version any more. Please verify if newer versions are affected with the reported problem. If that is the case, update the bug with a note, and update the version if you can. In case updating the version is not possible, leave a comment in this bug report with the version you tested, and set the "Need additional information the selected bugs from" below the comment box to "bugs". If there is no response by the end of the month, this bug will get automatically closed.
GlusterFS 3.4.x has reached end-of-life. If this bug still exists in a later release please reopen this and change the version or open a new bug.