Bug 486572
Summary: | libgfs2 requires arborial enlightenment | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Steve Whitehouse <swhiteho> |
Component: | gfs2-utils | Assignee: | Robert Peterson <rpeterso> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 11 | CC: | adas, agk, bmarzins, cfeist, fdinitto, swhiteho |
Target Milestone: | --- | Keywords: | FutureFeature |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Enhancement | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2010-03-10 21:14:58 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Steve Whitehouse
2009-02-20 12:07:35 UTC
The gfs2_bitmap_create code is old code, ported from gfs_fsck. The "0-based" versus "1-based" as I interpret it, means that the value goes from 0 to (size-1) rather than 1 to (size). Since malloc needs the size, they did the "+ 1". The code seems to work, so I opted not to mess with it. That's not to say there isn't room for improvement though. :7) As for the gfs2_block_mark code, that's for special block lists. These lists were done in order to save gfs2_fsck memory. In theory, the lists should be relatively small. I would hope gfs2_fsck would not find many "bad" blocks and I would hope it wouldn't find many duplicate blocks. If you have more than 100 of these blocks, your file system has some serious corruption and you're in trouble anyway. In actual practice, allocating a small linked list saves a lot of memory as opposed to a bitmap that spans to represent the entire file system which might be many TB in size. Historically speaking, when gfs_fsck runs out of memory, it's almost always due to having a bunch of huge bitmaps in memory. The CPU time to run the linked lists is cheap and fast, but if your node runs out of memory and into swap space, then gfs_fsck takes an enormous amount of time and agony. So there's a trade-off there until we can get a better system in place. The third list, eattr_blocks, is for extended attribute blocks. For most people, this list will also be very small. However, when we start talking about selinux labeling and such, the list could get quite large. So we'll have to re-think this. This all goes back to the best way to implement gfs_fsck. We've discussed doing this on an rg-by-rg basis, which would improve its memory usage enormously and allow us to run several threads in parallel, each cleaning up its own rg. The problem, of course, is when inodes in one RG references blocks in another RG, and we haven't sorted out the best way to implement that. This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Question for Steve: Most of this code has been completely reworked and now appears in the STABLE3 branch. Most of the linked lists have been replaced with rbtrees. The bitmap code has been simplified. Does that satisfy this bugzilla's requirements? Can I not just close this or is there still more work to be done? Setting NEEDINFO. Sounds like we are done with it then, thanks for fixing that up. |