Description of problem: If a object gets modified, then bit-rot-stub sends a notification to BitD to sign the object. BitD waits for sometime before signing the object so that if any modification happens within that time interval, it need not sign multiple times. And once the object is signed, its inode context is changed to indicate that, the inode is now in its default state. But if the inode gets forgotten after sending the sign notification to BitD, but before getting sign request, then when the sign request comes, the inode context says inode is in default state (instead of modified state) and does not sign the object. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
REVIEW: http://review.gluster.org/11729 (features/bit-rot-stub: handle REOPEN_WAIT on forgotten inodes) posted (#2) for review on master by Raghavendra Bhat (raghavendra)
REVIEW: http://review.gluster.org/11729 (features/bit-rot-stub: handle REOPEN_WAIT on forgotten inodes) posted (#3) for review on master by Venky Shankar (vshankar)
REVIEW: http://review.gluster.org/11729 (features/bit-rot-stub: handle REOPEN_WAIT on forgotten inodes) posted (#4) for review on master by Raghavendra Bhat (raghavendra)
Fix for this BZ is already present in a GlusterFS release. You can find clone of this BZ, fixed in a GlusterFS release and closed. Hence closing this mainline BZ as well.
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.8.0, please open a new bug report. glusterfs-3.8.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://blog.gluster.org/2016/06/glusterfs-3-8-released/ [2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user