| Summary: | afr: Internal locks need to [un]set lk_owners before and after [un]locking phases resp. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Community] GlusterFS | Reporter: | krishnan parthasarathi <kparthas> | ||||
| Component: | replicate | Assignee: | krishnan parthasarathi <kparthas> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | urgent | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | mainline | CC: | amarts, gluster-bugs, nsathyan, vbhat | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2012-03-13 17:49:29 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
*** Bug 790755 has been marked as a duplicate of this bug. *** CHANGE: http://review.gluster.com/2752 (afr: [Un]Set the 'right' lkowner for [f]{inode|entry}_lk and the 'enclosed' fop.) merged in master by Vijay Bellur (vijay) please update these bugs w.r.to 3.3.0qa27, need to work on it as per target milestone set. The above patch has been reverted. This bug will not be fixed, since a patch (under development) would make flush fops non-transaction in afr. Marking this as wont fix. |
Created attachment 562178 [details] Test app as mentioned in "steps to reproduce". Description of problem: inodelk, entrylk need to set lk_owner 'differently' to ensure two inode modify operations have different lk_owners. The issue is that they dont unset it after the internal locking phase is over, leaving posix lock fops have different owners despite coming from the same application. This can leave stale posix locks at the server(s). Version-Release number of selected component (if applicable): mainline How reproducible: Consistently Steps to Reproduce: 1. Hold a fcnlt F_WRLOCK on a section of a file via SETLK_W. 2. Kill the application holding the lock. 3. Run the app (See attachement for eg app) in Step 1 again and you will see a blocked posix lock. Actual results: Application in Step3 will see a blocked posix lock. Expected results: The application should not see a blocked lock. Additional info: Usage of attached app: - python <attached-app> <path of file to lock>