Back to bug 1305836

Who When What Removed Added
Red Hat Bugzilla Rules Engine 2016-02-09 11:29:19 UTC Keywords ZStream
Rejy M Cyriac 2016-02-19 17:42:40 UTC Blocks 1299184
Sakshi 2016-02-22 08:18:42 UTC Depends On 1310544
Nithya Balachandran 2016-02-26 04:26:37 UTC CC nbalacha
Assignee rhs-bugs sabansal
Alok 2016-03-04 05:50:35 UTC CC asrivast
Red Hat Bugzilla Rules Engine 2016-03-08 08:15:31 UTC Target Release --- RHGS 3.1.3
Sakshi 2016-03-23 10:21:54 UTC Status NEW MODIFIED
errata-xmlrpc 2016-03-24 13:18:04 UTC Status MODIFIED ON_QA
Satish Mohan 2016-03-24 16:09:46 UTC Fixed In Version glusterfs-3.7.9-1
Rahul Hinduja 2016-03-27 14:54:06 UTC QA Contact storage-qa-internal kramdoss
krishnaram Karthick 2016-05-10 06:20:49 UTC Status ON_QA VERIFIED
Sakshi 2016-05-10 10:40:54 UTC Doc Text Consequence: Renaming files takes non-blocking locks and hence can fail with EBUSY if there are parallel rename or rename and rebalance. This leads to application discontinuity.

Fix: Take blocking locks while renaming files.

Result: Rename files now gets blocked if the lock on file is acquired by another client doing rename or rebalance. Once the latter client completes the fop it grants the lock to the former client. This client completes the fop thereby avoiding application discontinuity.
Laura Bailey 2016-06-06 06:42:33 UTC Doc Text Consequence: Renaming files takes non-blocking locks and hence can fail with EBUSY if there are parallel rename or rename and rebalance. This leads to application discontinuity.

Fix: Take blocking locks while renaming files.

Result: Rename files now gets blocked if the lock on file is acquired by another client doing rename or rebalance. Once the latter client completes the fop it grants the lock to the former client. This client completes the fop thereby avoiding application discontinuity.
File renaming operations took non-blocking locks, which meant that they could fail with EBUSY or ESTALE errors when other rename or rebalance operations were in progress. This could lead to inconsistent state. Blocking locks are now used for file renaming operations, so file renaming operations are now blocked if the file lock is acquired by another client performing a rename or rebalance. After the other client completes the file operation, it grants the lock to the client, which completes the operation. This avoids the problem of inconsistent state.
Flags needinfo?(sabansal)
Sakshi 2016-06-14 03:40:40 UTC Flags needinfo?(sabansal)
Laura Bailey 2016-06-14 03:46:52 UTC Doc Text File renaming operations took non-blocking locks, which meant that they could fail with EBUSY or ESTALE errors when other rename or rebalance operations were in progress. This could lead to inconsistent state. Blocking locks are now used for file renaming operations, so file renaming operations are now blocked if the file lock is acquired by another client performing a rename or rebalance. After the other client completes the file operation, it grants the lock to the client, which completes the operation. This avoids the problem of inconsistent state. File renaming operations took non-blocking locks, which meant that they could fail with EBUSY or ESTALE errors when other rename or rebalance operations were in progress. This could lead to a lack of application continuity when the file renaming operation did not succeed. Blocking locks are now used for file renaming operations, so that file operations are blocked until the lock releases. When the file renaming operation is granted the lock, the application continues with the renaming operation, avoiding applicaton continuity problems.
Flags needinfo?(sabansal)
Sakshi 2016-06-14 03:58:50 UTC Flags needinfo?(sabansal)
errata-xmlrpc 2016-06-23 00:48:06 UTC Status VERIFIED RELEASE_PENDING
errata-xmlrpc 2016-06-23 05:07:11 UTC Status RELEASE_PENDING CLOSED
Resolution --- ERRATA
Last Closed 2016-06-23 01:07:11 UTC
John Skeoch 2016-08-01 01:22:21 UTC CC smohan

Back to bug 1305836