Description of problem: When multiple writes are sent in parallel and one of them fails, a following fsync should wait until all other writes finish. Version-Release number of selected component (if applicable): mainline How reproducible: Always on NetBSD, though it's not easily visible from an application unless a side effect is checked. Steps to Reproduce: 1. create a dispersed volume and limit a directory with quota 2. write a file larger than the assigned quota on that directory (it will fail) 3. immediately after failing (it should be done very fast, like in a script), delete the file. 4. glusterfs will crash because file is closed after fsync and some of the pending writes return ENOENT and this is unexpected in DHT (not sure why ENOENT though) Actual results: Control is returned to the user before all pending write have finished. Expected results: The call should block the application until all pending writes are fully processed. Additional info:
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.7.0, please open a new bug report. glusterfs-3.7.0 has been announced on the Gluster mailinglists [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/10939 [2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user