Back to bug 1320412
| Who | When | What | Removed | Added |
|---|---|---|---|---|
| Red Hat Bugzilla Rules Engine | 2016-03-23 07:29:49 UTC | Keywords | ZStream | |
| Ashish Pandey | 2016-03-23 07:30:25 UTC | Status | NEW | ASSIGNED |
| Assignee | rhs-bugs | aspandey | ||
| Rahul Hinduja | 2016-03-29 09:23:12 UTC | CC | rhinduja | |
| Alok | 2016-04-01 09:59:10 UTC | CC | asrivast | |
| Red Hat Bugzilla Rules Engine | 2016-04-05 10:07:40 UTC | Target Release | --- | RHGS 3.1.3 |
| Pranith Kumar K | 2016-04-05 10:25:44 UTC | Status | ASSIGNED | MODIFIED |
| CC | pkarampu | |||
| Rahul Hinduja | 2016-04-07 08:34:15 UTC | Blocks | 1311817 | |
| Rahul Hinduja | 2016-04-07 08:36:32 UTC | QA Contact | byarlaga | nchilaka |
| Rejy M Cyriac | 2016-04-18 05:49:34 UTC | CC | rcyriac | |
| errata-xmlrpc | 2016-04-20 11:24:16 UTC | Status | MODIFIED | ON_QA |
| Satish Mohan | 2016-04-20 11:28:59 UTC | Fixed In Version | glusterfs-3.7.9-2 | |
| Nag Pavan Chilakam | 2016-05-03 11:50:42 UTC | Status | ON_QA | VERIFIED |
| Ashish Pandey | 2016-05-13 09:05:20 UTC | Doc Text | Cause: If a fop takes lock, and completes its operation, it waits for 1 second before releasing the lock. However, If ec find any lock contention within this time period, it release the lock immediately before time expires. As we take lock on first brick, for few operations, like read, it might happen that discovery of lock contention might take long time and can degrades the performance. Consequence: Poor performance in data/metadata read. Fix: Provide an option to enable/disable eager lock. If eager lock is disabled, lock will be released as soon as fop completes. Result: gluster v set <VOLUME NAME> disperse.eager-lock on gluster v set <VOLUME NAME> disperse.eager-lock off |
|
| Laura Bailey | 2016-06-06 01:52:04 UTC | CC | aspandey | |
| Doc Text | Cause: If a fop takes lock, and completes its operation, it waits for 1 second before releasing the lock. However, If ec find any lock contention within this time period, it release the lock immediately before time expires. As we take lock on first brick, for few operations, like read, it might happen that discovery of lock contention might take long time and can degrades the performance. Consequence: Poor performance in data/metadata read. Fix: Provide an option to enable/disable eager lock. If eager lock is disabled, lock will be released as soon as fop completes. Result: gluster v set <VOLUME NAME> disperse.eager-lock on gluster v set <VOLUME NAME> disperse.eager-lock off | Before a file operation starts, a lock is placed on the file. The lock remains in place until the file operation is complete. After the file operation completed, the lock remained in place either until lock contention was detected, or for 1 second in order to check for another request for that file from the same client. This reduced performance, but improved access efficiency. This update provides a new volume option, disperse.eager-lock, to give users more control over lock time. If eager-lock is on (default), the previous behavior applies. If eager-lock is off, locks release immediately after file operations complete, improving performance for some operations, but reducing access efficiency. | ||
| Doc Type | Bug Fix | Enhancement | ||
| Flags | needinfo?(aspandey) | |||
| Ashish Pandey | 2016-06-10 04:42:44 UTC | Flags | needinfo?(aspandey) | |
| errata-xmlrpc | 2016-06-23 00:51:12 UTC | Status | VERIFIED | RELEASE_PENDING |
| errata-xmlrpc | 2016-06-23 05:13:53 UTC | Status | RELEASE_PENDING | CLOSED |
| Resolution | --- | ERRATA | ||
| Last Closed | 2016-06-23 01:13:53 UTC | |||
| Rejy M Cyriac | 2016-09-17 15:03:53 UTC | Sub Component | disperse | |
| CC | rhs-bugs, storage-qa-internal | |||
| Component | glusterfs | disperse |
Back to bug 1320412