+++ This bug was initially created as a clone of Bug #1214649 +++ Description of problem: ======================= BitRot :- When all fds are closed on files, file will be candidate for signing. If file is reopened for writing in next 120 second then it should be removed from queue Version-Release number of selected component (if applicable): ============================================================= 0.803.gitf64666f.el6.x86_64 How reproducible: ================= always Steps to Reproduce: =================== 1. create and mount volume. 2. enable bitrot. 3. create few files. 4. open for write and close it. 5. repeat step 4 for 3-4 times within 5 seconds. Actual Result:- =============== File is not being removed from signing queue if re opened within 120 second and signed multiple times Expect Result:- =============== File should be removed from signing queue if reopened for writing in 120 second --- Additional comment from Venky Shankar on 2015-05-06 00:05:35 EDT --- --- Additional comment from Raghavendra Bhat on 2015-05-08 05:49:28 EDT --- This issue has been taken care in the patch sent to handle anonymous fd writes (1207979). http://review.gluster.org/#/c/10233/ takes care of that. But still there is a small window of multiple notifications on the same gfid being present in the timer wheel if the inode is forgotten in the brick after sending a notification to BitD, but before the notification entry expires from timer-wheel a new write and release happens on that gfid in the brick (now on a newly looked up inode). This window is pretty negligible in real world use cases. Hence not marking the bug as modified. But its not a point of concern as of now. --- Additional comment from Venky Shankar on 2015-05-16 04:09:51 EDT --- Moving this BZ back to NEW as this scenario is taken care indirectly by the anonfd patch (already merged). As per Comment #2 by Johnny, the probability of the scenario happening is pretty negligible. Therefore, I'll propose not to track this BZ unless the impact of this bug is experienced more often. --- Additional comment from Venky Shankar on 2015-05-18 06:08:14 EDT --- Rajesh/Anoop, We're not planning to fix this as of now (read comment #2 and #3 for explanation). Any concerns?
This is indirectly taken care by a slight change in the algorithm. Therefore, this is not planned to be fixed. Rajesh, comments?