RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 679566 - gfs2_edit savemeta doesn't save all leaf blocks for large dirs
Summary: gfs2_edit savemeta doesn't save all leaf blocks for large dirs
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: cluster
Version: 6.1
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: rc
: ---
Assignee: Robert Peterson
QA Contact: Cluster QE
URL:
Whiteboard:
Depends On: 679565
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-02-22 21:23 UTC by Robert Peterson
Modified: 2011-12-06 14:50 UTC (History)
9 users (show)

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.
Clone Of: 679565
Environment:
Last Closed: 2011-12-06 14:50:54 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
RHEL6 patch (2.09 KB, patch)
2011-04-08 16:23 UTC, Robert Peterson 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1516 0 normal SHIPPED_LIVE cluster and gfs2-utils bug fix update 2011-12-06 00:51:09 UTC

Description Robert Peterson 2011-02-22 21:23:19 UTC 
+++ This bug was initially created as a clone of Bug #679565 +++
Crosswrite to RHEL6

Description of problem:
If you have a large enough directory, gfs2_edit savemeta
won't save all of its leaf blocks.

Version-Release number of selected component (if applicable):
RHEL56

How reproducible:
Always

Steps to Reproduce:
1. mkfs.gfs2 -O -t bobs_roth:roth_lv -p lock_dlm -j 4 /dev/roth_vg/roth_lv
2. mount -tgfs2 /dev/roth_vg/roth_lv /mnt/gfs2
3. mkdir /mnt/gfs2/bigdir
4. for i in `seq 1 543562` ; do dd if=/dev/zero of=/mnt/gfs2/bigdir/gfs2.$i bs=4K count=3 &>/dev/null; done
5. umount /mnt/gfs2
6. gfs2_edit savemeta /dev/roth_vg/roth_lv halfamillion12Kfiles.meta
7. gfs2_edit printsavedmeta halfamillion12Kfiles.meta > /tmp/gronk
8. grep "directory leaf" /tmp/gronk | wc -l
  
Actual results:
0

Expected results:
10214


Additional info:
Patch in hand

--- Additional comment from rpeterso on 2011-02-22 16:22:25 EST ---

Requesting ack flags for 5.7.
Comment 1 Robert Peterson 2011-02-22 21:24:42 UTC 
Requesting ack flags for rhel6
Comment 2 Robert Peterson 2011-04-08 16:23:52 UTC 
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.
Comment 3 Robert Peterson 2011-05-26 18:35:17 UTC 
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.
Comment 4 Robert Peterson 2011-05-26 18:35:17 UTC 
    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.
Comment 5 Fabio Massimo Di Nitto 2011-05-27 06:48:41 UTC 
The original commit landed at the wrong time and I had to revert/reapply.

New sha1 is: 258fd452647c6210e68f9528c723e3a49d77dbfa
Comment 9 errata-xmlrpc 2011-12-06 14:50:54 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.