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 1382087 - gfs2_edit: savemeta does not save leaf chain blocks
Summary: gfs2_edit: savemeta does not save leaf chain blocks
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gfs2-utils
Version: 7.4
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: rc
: ---
Assignee: Andrew Price
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On: 1413684
Blocks: 1385242
TreeView+ depends on / blocked
 
Reported: 2016-10-05 17:15 UTC by Robert Peterson
Modified: 2017-08-01 21:57 UTC (History)
3 users (show)

Fixed In Version: gfs2-utils-3.1.10-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-01 21:57:28 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Script used to recreate the problem (1.39 KB, text/plain)
2016-10-05 17:19 UTC, Robert Peterson 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:2226 0 normal SHIPPED_LIVE gfs2-utils bug fix and enhancement update 2017-08-01 18:43:08 UTC

Description Robert Peterson 2016-10-05 17:15:59 UTC 
Description of problem:
The gfs2_edit savemeta feature does not save leaf chain blocks.
These are cases where a dinode's leaf block points to another
"chain" leaf block via lf_next.
We need to fix gfs2_edit so that it saves all leaf chain blocks.

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

How reproducible:
Always

Steps to Reproduce:
Something like this:

mkfs.gfs2 -O -j1 -plock_nolock /dev/sasdrives/scratch |grep "groups"
mount -tgfs2 /dev/sasdrives/scratch /mnt/gfs2
cd /mnt/gfs2
/home/bob/tools/bz1138749_tests/100_names.sh
cd -
umount /mnt/gfs2
gfs2_edit savemeta /dev/sasdrives/scratch /tmp/100names.with.same.hash.meta.gz
gfs2_edit -p 0x8349 /dev/sasdrives/scratch |grep lf_next
gfs2_edit printsavedmeta /tmp/100names.with.same.hash.meta.gz |grep 0x8349
gfs2_edit printsavedmeta /tmp/100names.with.same.hash.meta.gz |grep 0x834a

Actual results:
Block 0x834a does not appear in the printsavedmeta output because it
was never saved. That's the problem.

Expected results:
33644 (l=0xff8): Block #33610    (0x834a) (directory leaf)

Additional info:
The steps given above do this:
1. A new GFS2 file system is made and mounted
2. The script creates enough files with a duplicate hash value
   that the leaf block is forced into a chain leaf block. In
   this case, block 0x834a is the chain leaf block.
3. The file system is unmounted and the metadata saved to a file.
4. The leaf block at 0x8349 is printed to prove we have a non-zero
   value for lf_next.
5. The first printsavedmeta proves we saved that leaf which has
   the forward chain.
6. The second printsavedmeta proves gfs2_edit savemeta did or did
   not save the chain leaf block.
Comment 1 Robert Peterson 2016-10-05 17:19:49 UTC 
Created attachment 1207653 [details]
Script used to recreate the problem

Ben Marzinski created this script to touch one hundred files
that all have the same hash value, which forces GFS2 to put
some of them on a leaf chain block.
Comment 2 Robert Peterson 2016-10-05 17:20:53 UTC 
This should be easy to fix. Setting devel_ack flag for 7.4
Comment 3 Andrew Price 2017-01-16 16:51:45 UTC 
The fix for this has gone upstream <https://git.fedorahosted.org/cgit/gfs2-utils.git/commit/?id=b4333e4109d0> so it will be pulled in when gfs2-utils is rebased.
Comment 6 Justin Payne 2017-05-24 17:09:57 UTC 
Verified in gfs2-utils-3.1.10-3.el7:

[root@host-008 ~]# rpm -q gfs2-utils
gfs2-utils-3.1.10-3.el7.x86_64
[root@host-008 ~]# mkfs.gfs2 -O -j1 -plock_nolock /dev/sda |grep "groups"
Building resource groups: Done
Resource groups:           801
[root@host-008 ~]# mount -tgfs2 /dev/sda /mnt/gfs2
[root@host-008 ~]# cd /mnt/gfs2
[root@host-008 gfs2]# /root/100_names.sh 
[root@host-008 gfs2]# cd -
/root
[root@host-008 ~]# umount /mnt/gfs2
[root@host-008 ~]# gfs2_edit savemeta /dev/sda 100names.with.same.hash.meta.gz
There are 52428798 blocks of 4096 bytes in the filesystem.
Filesystem size: 199.1023GB
52428798 blocks processed, 37876 saved (100%)

Metadata saved to file 100names.with.same.hash.meta.gz (gzipped, level 9).

[root@host-008 ~]# gfs2_edit -p root /dev/sda |grep Dir
Directory block: lf_depth:17, lf_entries:83, lf_inode: 0x8178, lf_dist: 1, lf_nsec: 10215949, lf_sec: 1495588000, fmt:1200 next=0x83ad (83 dirents).
[root@host-008 ~]# gfs2_edit printsavedmeta 100names.with.same.hash.meta.gz |grep 0x83ad
33663 (l=0x398): Block #33709    (0x83ad) (directory leaf)
Comment 7 errata-xmlrpc 2017-08-01 21:57:28 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.

https://access.redhat.com/errata/RHBA-2017:2226
Note You need to log in before you can comment on or make changes to this bug.