Bug 698394
Summary: | GFS2: rlist code should be removed once it is no longer used | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Steve Whitehouse <swhiteho> |
Component: | kernel | Assignee: | Steve Whitehouse <swhiteho> |
Status: | NEW --- | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | low | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | adas, anprice, bmarzins, collura, gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, rpeterso |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | Type: | --- | |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 236102 | ||
Bug Blocks: | 790188 |
Description
Steve Whitehouse
2011-04-20 19:31:54 UTC
One solution to this is to get rid of the rlist code entirely. This should be possible if we can remove the two users of this code. These are: o Deallocation of dir leaf blocks o Deallocation of indirect block tree o Deallocation of indirect xattr tree blocks It should be possible to redesign the code to work in the opposite way to the allocation code in order to only lock a single rgrp at a time and thus resolve the locking order issue. This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19 *********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.11.1-200.fc19. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those. *********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.12.6-200.fc19. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 20, and are still experiencing this issue, please change the version to Fedora 20. If you experience different issues, please open a new bug report for those. Indirect block deallocations now no longer use the rlist code. That leaves two callers: gfs2_dir_exhash_dealloc() and ea_dealloc_indirect() The direcotry code can be easily updated to be more efficient, although it is very likely to be dealing with many scattered blocks. The algorithm should be something along the lines of: 1. Find first leaf block to deallocate 2. Lock that rgrp 3. See how many other leaf blocks are in the same rgrp, by (a) scanning down the chain until we hit a block in another rgrp and (b) repeating that for every hash chain 4. Deallocating the leaf blocks in question 5. Updating the hash chain headers 6. Repeating until all hash chains are empty That way each transactions (one per rgrp) ensures that everything remains consistent while the hash chains are deallocated. The iteration means that we no longer need to use the rlist code. A similar approach could be used for the EA blocks too, and then the rlist code can be removed entirely. |