Bug 679566
Summary: | gfs2_edit savemeta doesn't save all leaf blocks for large dirs | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Robert Peterson <rpeterso> | ||||
Component: | cluster | Assignee: | Robert Peterson <rpeterso> | ||||
Status: | CLOSED ERRATA | QA Contact: | Cluster QE <mspqa-list> | ||||
Severity: | low | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 6.1 | CC: | ccaulfie, cluster-maint, djansa, edamato, fdinitto, lhh, mjuricek, rpeterso, teigland | ||||
Target Milestone: | rc | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | cluster-3.0.12.1-2.el6 | Doc Type: | Bug Fix | ||||
Doc Text: |
Cause
A user performs the command "gfs2_edit savemeta" to save off the metadata for a target GFS2 file system. However, not all of the directory information is saved for large directories. If the metadata is restored to another device, fsck.gfs2 will find directory corruption due to missing leaf blocks.
Consequence
The bug was caused because gfs2_edit was treating the directory leaf index (known as the directory hash table) like it did a normal data file. In other words, a collection of metadata blocks. For a normal data file gfs2_edit needs to save only the metadata blocks, but not the user's data blocks. For a directory, gfs2_edit needs to save the "data" because the "data" blocks are the actual
directory hash table, and the blocks beneath it are the directory leaf blocks that also need to be saved.
Fix
The fix was to change gfs2_edit's savemeta function to actually read all the data (i.e. the directory hash table) for large directories and traverse the hash table, saving all the leaf blocks.
Result
With the directory hash table processed properly, all leaf blocks are saved properly.
|
Story Points: | --- | ||||
Clone Of: | 679565 | Environment: | |||||
Last Closed: | 2011-12-06 14:50:54 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: | |||||||
Bug Depends On: | 679565 | ||||||
Bug Blocks: | |||||||
Attachments: |
|
Description
Robert Peterson
2011-02-22 21:23:19 UTC
Requesting ack flags for rhel6 Created attachment 490835 [details]
RHEL6 patch
Ran into this bug while working on a customer critsit,
so I had to crosswrite the patch. So here it is.
Verified it on RHEL6 system gfs-i24c-01.
Patch 0ce6e00 was pushed to the RHEL6 branch of the cluster.git tree for inclusion into 6.2. Changing status to POST until this gets built. Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cause A user performs the command "gfs2_edit savemeta" to save off the metadata for a target GFS2 file system. However, not all of the directory information is saved for large directories. If the metadata is restored to another device, fsck.gfs2 will find directory corruption due to missing leaf blocks. Consequence The bug was caused because gfs2_edit was treating the directory leaf index (known as the directory hash table) like it did a normal data file. In other words, a collection of metadata blocks. For a normal data file gfs2_edit needs to save only the metadata blocks, but not the user's data blocks. For a directory, gfs2_edit needs to save the "data" because the "data" blocks are the actual directory hash table, and the blocks beneath it are the directory leaf blocks that also need to be saved. Fix The fix was to change gfs2_edit's savemeta function to actually read all the data (i.e. the directory hash table) for large directories and traverse the hash table, saving all the leaf blocks. Result With the directory hash table processed properly, all leaf blocks are saved properly. The original commit landed at the wrong time and I had to revert/reapply. New sha1 is: 258fd452647c6210e68f9528c723e3a49d77dbfa Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2011-1516.html |