Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
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

Summary: gfs2_edit: savemeta does not save leaf chain blocks
Product: Red Hat Enterprise Linux 7 Reporter: Robert Peterson <rpeterso>
Component: gfs2-utilsAssignee: Andrew Price <anprice>
Status: CLOSED ERRATA QA Contact: cluster-qe <cluster-qe>
Severity: low Docs Contact:
Priority: unspecified    
Version: 7.4CC: cluster-maint, gfs2-maint, jpayne
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: gfs2-utils-3.1.10-1.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-08-01 21:57:28 UTC Type: Bug
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: 1413684    
Bug Blocks: 1385242    
Attachments:
Description Flags
Script used to recreate the problem none

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